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Incredibly affordable price. $595.00 per 
module. These modular tools give your 
company the ability to grow in CASE power. 

The modules of the Workbench build upon 
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for reuse in other projects. Boilerplates allow diagrams to be customized. 
Diagrams can be output in presentation quality using HP laser printers. Entire 
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Error reports are output to screen or hardcopy. And the analysis takes place 
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allowed. 
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VISIBLE DICTIOMARY - MODULE C 

Visible Dictionary is the central data repository 
for the system being modeled. It Is multi-user 
and interactive. Many users may access it 
simultaneously. Full file and record locking 
capabilities keep users from colliding and 
corrupting d,. 1 


_,____j. Visible Dictionary has many 

powerful features including: "where used" listings, wild card searches and 
finds, full import/export, automatic entry generation and entry updating, on¬ 
line accessability from diagrams, many different entry types, customized 
report formatting, and much more. The Dictionary organizes, reports, and 
categorizes all project data. File format information is provided for data 
transfers in A5CII format. The specification developed using the Visible 
Workbench becomes a company asset that can be used to build upon in later 
stages of the systems development lifecycle. 
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President’s MESSAGE 


Kenneth R. Anderson 


Preparing for the technology of the 21st century 

1989: the year of technical, educational, and area activities 


F or Computer Society members and other computing 
professionals, these are exciting times. Over the last 
20 years we have seen computers advance to play a 
critical role in the economy of every industrialized nation. 
Today there are very few processes or activities of any 
appreciable complexity that do not depend in whole or in sig¬ 
nificant part on an intelligent machine. Further, the applica¬ 
tion of computers to such global problem areas as earth 
sciences and weather modeling has elevated information sys¬ 
tems technology to a role that transcends national boundaries 
and politics. 

The IEEE Computer Society has been fortunate to share in 
this excitement and growth. In the last decade alone, our 
membership has nearly tripled, to more than 100,000 at our 
January count. Our technical committees have expanded 
from 18 to 33, our periodicals from two to 10, our confer¬ 
ences from about 50 to over 100, our standards projects from 
a dozen to over 100, and our annual budget from $2 million 
to $17 million. Our bases of operations have expanded from 
Washington, DC, and California to include a European 
office in Brussels and an Asian office in Tokyo. Our volun¬ 
teers and staff are linked via electronic mail, our staff is 
implementing electronic publishing technology to produce 
our magazines, and just this last year the Technical Activities 
Board produced and cosponsored, with the IEEE Educa¬ 
tional Activities Board, our first satellite symposium — Com- 
pusat 88. This satellite symposium linked more than 130 
receiving sites throughout the western hemisphere and 
included many colleges and universities. (See the article on p. 
130 for details.) 

It is commonplace to observe that people are key to the 
success of any organization, and certainly that is true with the 
Computer Society. For without the coordinated efforts of 
more than 4,000 volunteers and our staff of 84, the impres¬ 
sive achievements listed above would have been impossible. 
Indeed, it has become a hallmark of our operation in recent 
years that the first Executive Committee meeting of the year 


pairs up the key volunteer-staff team members, such as the 
vice president for membership and information with the 
membership/circulation promotion manager, or the vice 
president for conferences with the director of conferences and 
meetings, to develop specific plans and goals for the coming 
year. I am proud to continue and build upon that tradition of 
teamwork, and at this writing plans are underlay for our 
1989 planning sessions scheduled for January 11-13 in Wash¬ 
ington, DC. 

For me, one of the high-priority projects we will address in 
Washington is our public relations plan for 1989. The spade- 


How do you feel about instituting 
Local Activity Centers 
to make our programs more geographically 
convenient? 

To express your opinion, select the statement that best 
matches your view and circle its number on the Reader 
Service Card (p. 160A). 
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in my area. 

162 — Agree, but must limit current participation to 
attendance only. 

163 — Neutral or need more details. 

164 — Disagree; other programs are more vital. (Please 
list your top priorities in the space for comments on the 
other side of the card). 
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work carried out last year by Past President Ed Parrish and 
former Vice President for Membership and Information Mer¬ 
lin Smith culminated in the approval by the society’s Board 
of Governors of the concept of engaging a public relations 
firm to help us achieve proper public recognition of the soci¬ 
ety’s efforts in such key areas as technical activities, educa¬ 
tion, standards, conferences, and publications. I’ll keep you 
posted on this as our plan develops. 

Sustaining our tradition of program excellence and aggres¬ 
sive growth will require an increase in our most important 
resource — people. To that end, we will need innovative 
approaches to attract new members and new volunteers into 
our ranks, and I hope the ideas suggested below will help 
accomplish that. 

Excellent programs do not, by themselves, ensure our 
future growth and success; our programs and services must 
also be readily accessible. We need to develop ways to bring 
our full range of activities to members in their own geo¬ 
graphic areas — that is, to make participation easier and 
more convenient. One way is through programs such as our 
recent satellite conference, Compusat 88, which was received 
at 130 sites and viewed by some 6,000 participants. Another 
way is by increasing the number of our regional conferences 
and workshops and by establishing what, for now. I’ll call 
“local activity centers” within our current office locations. 
Our Area Activities Board is currently investigating the feasi¬ 
bility of initiating new geographically localized activities. I’ll 
keep you posted as the board’s plans develop. For now, I’d 
appreciate your expression of interest (or lack of interest) in 
the general idea. Please use the Reader Service Card to indi¬ 
cate the statement in the accompanying box that most nearly 
represents your point of view. 

Satellite conferences and regional activities are only two of 
many ideas we need to evaluate as we consolidate the gains of 
the last 10 years, plan for the next decade, and prepare for 
the technology of the 21st century. My personal vision for the 
Computer Society at the year 2,000 is as follows: 

(1) Membership will exceed 170,000 and will cover a wider 
range of applications and allied interests such as geophysics, 
earth science, manufacturing, the humanities, and the arts. 

(2) The number of active volunteers will have increased to a 
minimum of 10,000, many of whom will be engaged in mul¬ 
tidisciplinary activities and serving on teams at “activity 
centers” throughout the world. 

(3) Our programs and services will make extensive use of 
the information age technologies — for example, video, 
visualization, database, and communications — that we pre¬ 
sent at our technical forums but do not always use for society 
activities. 

(4) The society will be a focal point for articulating the 
views and aspirations of its members and for providing 
sociotechnical information to the general public and to public 
policy decision-makers. 

(5) Our vision, teamwork, and entrepreneurial spirit will be 
the main attributes of our continued success. 

I am proud to have the opportunity to serve as president 
of the Computer Society during 1989, and I view it as a 
time to start preparing for the technology of the 21st 
century. Please join us — the 4,000 or more volunteers and 
staff now involved — in shaping the future. 

Kenneth R. Anderson 
President 
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Guest Editor’s Introduction 


Real Machines 

Design Choices/Engineering Trade-Offs 

Yale N. Patt 
University of Michigan 


T his special issue addresses the 
business of producing computing 
machines and the choices com¬ 
puter architects and implementors must 
make to succeed in the marketplace. This 
focus represents the sober reflection that 
computer architecture is not yet a science, 
even though parts of the discipline can be 
considered science and most of it often 
involves scientific methodology. To a large 
extent, the field is not driven by an interest 
in finding order in what appears to be 
chaos, but rather by an interest in produc¬ 
ing a product that people will buy. 

To produce that product, architects and 
implementors have a budget, whether 
measured in dollars, gates, person-years, 
or similar entities, with which to achieve 
a certain functional capability at a speci¬ 
fied performance level. Within those con¬ 
straints, many choices are available. This 
issue of Computer examines these choices 
within the context of specific machine 
designs. Some of these choices and a 
framework for their consideration are 
identified below. 


Levels of transformation 

A problem to be solved by the computer 
is first formulated in a natural language. 
Between the initial formulation and the 
final solution are several levels of transfor¬ 
mation. The problem is first transformed 
into an algorithm, a step-by-step proce¬ 



dure wherein each step is both effective 
(that is, able to be carried out) and definite 
(precise). The problem is then represented 
by a (usually high-level) mechanical lan¬ 
guage and translated to the target 
machine’s instruction set architecture 
(ISA). The target machine can be a single 
processor or a set of processors configured 
to do more than one thing concurrently, 
thereby obtaining a performance advan¬ 
tage. Finally, each instruction in the ISA 
program is interpreted by the microar¬ 
chitecture (that is, host machine) that has 
been designed to implement the target 
machine. 

A cost/performance edge is achieved by 


careful selection from the choices available 
at all levels of the transformation struc¬ 
ture. For our part, these choices come 
from three places: 

(1) the host machine or microarchitec- 
tural level (choices related to the processor 
implementation and transparent to the 
software), 

(2) the ISA level (choices related to the 
ISA and visible to the software), and 

(3) the system level (choices related to 
the configuration of processors, memory, 
and switches). 

ISA-level choices 

Dynamic/static interface. The instruc¬ 
tion set architecture represents the inter¬ 
face between the completion of static 
translation by a compiler or assembler and 
the beginning of dynamic interpretation 
and subsequent control of the microen¬ 
gine. Perhaps the most important choice 
computer architects make is the level at 
which they specify this interface. We call 
it the DSI, for dynamic/static interface. 

The architectural choices here involve 
deciding how to handle complexity — by 
the compiler (as in the case of a rich, low- 
level DSI) or by the data path (as in the case 
of large atomic units in a high-level DSI). 1 

Concurrency. How to exploit concur¬ 
rency must be considered at each transfor¬ 
mational level. For the ISA level, it 
involves the number of operations issued 
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per cycle, whether execution of these oper¬ 
ations is in lock-step or decoupled, and 
how the execution is controlled. The issue 
of control involves choosing control flow 
via a program counter or data flow. The 
choices are the following: 

(1) traditional single-instruction stream, 
single-data stream (SISD) machines, such 
as your favorite VAX or System 370; 

(2) single-instruction stream, multiple- 
data stream (SIMD) machines such as the 
Illiac IV 2 of 20 years ago and, more 
recently, the Connection Machine 3 ; 

(3) very long instruction word (VLIW) 
machines such as the Multiflow TRACE, 4 
the Cydra 5, 5 and the original Stanford 
MIPS 6 ; and finally, 

(4) the decoupled instruction approach 
embodied in the SMA work 7 at Illinois, 
the DAE and PIPE 8 work at Wisconsin, 
and the HPS work 9 initiated at UC Ber¬ 
keley and continuing at Illinois and Michi¬ 
gan, where concurrency is exploited and 
performance enhanced at additional hard¬ 
ware cost. 

Register file. An ISA choice that must 
be made in conjunction with the imple¬ 
mentation strategy is the structure of the 
register file, both its size and format. The 
number of sets of physical registers, how 
many sets are visible to the software, 
whether or not they overlap, the number 
addressable at any one time, and how they 
can be accessed (for example, directly or 
via a stack pointer) are all matters of 
choice in specifying the ISA. However, the 
selection is not entirely an ISA issue since 
the registers compete for chip or board 
space with other features, many of which 
are not visible to the ISA. 

Microarchitecture-level 

choices 

The microarchitecture is what goes on 
under the hood, as opposed to the archi¬ 
tecture, which is what goes on inside the 
car. The features provided by the microar¬ 
chitecture are not visible to the software, 
but they largely determine the raw perfor¬ 
mance of a given ISA implementation. 
Their selection is based on expected per¬ 
formance benefits versus the cost of inclu¬ 
sion. Invariably, there is some budget — 
real estate on the chip, chips on the board, 
boards in the system, available power, and 
so on — for which the various microar¬ 
chitecture (host machine) choices 
compete. 


Among the choices at the microarchitec¬ 
ture level are the following: 

(1) concurrency through pipelining, 
with the additional choice of keeping the 
pipeline full in the presence of conditional 
branches by either replicating the pipe¬ 
line’s first few stages, changing branch- 
instruction semantics to implement a 
delayed branch, or applying compile time 
or runtime branch prediction. 

(2) support for out-of-order execution, 
which usually includes implementing a 
hardware mechanism such as a register 
scoreboard or the Tomasulo algorithm of • 
the IBM 360/91 floating-point unit. 10 

(3) hot versus warm functional unit sup¬ 
port, which requires choosing between 
developing a special-purpose attached 
processor or using the existing microar¬ 
chitecture and additional microcode to 
execute at slower speed. As the use of 
application-specific integrated circuits 
increases, this choice continues to opt in 
the direction of higher performance. 

(4) functional partitioning, which 
involves choices at two levels — optimiz¬ 
ing chip real estate and distributing the 
processing, memory, and control among 
the chip set. Choices for what to put on the 
chip include microcode, floating-point 
coprocessor, branch target buffer, stack 
cache, multiple register windows, postde¬ 
code cache, and on-chip cache. With 
respect to functional distribution, we can, 
for example, put the processing element on 
one chip, the memory on another chip, 
and the control on a third chip, or we can 
put some memory, some processing, and 
some control on each chip. 

System-level choices 

Choices at the system level involve con¬ 
figuring processors, storage, I/O, and 
interconnection structures into a computer 
system. These choices involve some of the 
trade-offs listed below. 

The choice of supercomputer versus 
multimicro is the choice of delivering 2" 
MIPS by offering one processor delivering 
2" MIPS or 2" processors delivering one 
MIPS each. Historically, the former has 
been referred to as a supercomputer, 
although the supercomputers of today 
have more than one processor (the Cray-2 
has four processors, for example). The lat¬ 
ter has come to be called a multimicro. 11 
The choice is in part due to the ability to 
harness the apparent (aka peak) power 
provided and the cost per MIPS for that 
power. 


The choice of tightly coupled versus 
loosely coupled multiprocessing is the 
choice of shared memory versus message 
passing. Shared memory provides poten¬ 
tially higher performance, but there are 
serious caveats, such as contention for 
memory and I/O and cache consistency, 
which can produce lower performance 
than that obtained with a message-passing, 
loosely coupled multiprocessing scheme. 

Whether to use vector processing or 
VLIW (or neither) is a choice between two 
mechanisms for exploiting the regular par¬ 
allelism most commonly found in scien¬ 
tific programming. 

The choice of using a tailored ISA 
versus a commodity part is based on the 
need to balance the higher cost of the tai¬ 
lored part against the additional perfor¬ 
mance it provides. 

The choices associated with the I/O 
architecture involve the most ad hoc of the 
systems issues, including whether and how 
much buffering to do, whether to use a 
synchronous or an asynchronous system 
bus, and whether to use a standard or tai¬ 
lored special-purpose bus. 

Interconnection networks provide 
choices involving the topology and the 
switching scheme. Typical topologies are 
the mesh, tree, cube-connected cycle, 
hypercube, bus, and ring. The most com¬ 
mon switching schemes are packet switch¬ 
ing and circuit switching. The trade-offs 
are contention, latency, cost, and flexi¬ 
bility. 

T his introduction has only 
scratched the surface of the deci¬ 
sion processes associated with 
delivering a marketable computer system. 
The articles in this issue of Computer will 
take you through more details pertaining 
to six real designs. I trust you will find the 
discussions useful. □ 
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T he Cydra 5 Departmental Super¬ 
computer targets small work 
groups or departments of scien¬ 
tists and engineers. 1 It costs about the 
same as a high-end superminicomputer 
($500,000 to $1 million), but it can achieve 
about one-third to one-half the perfor¬ 
mance of a supercomputer costing $10 to 
$20 million. This results from using high¬ 
speed, air-cooled, emitter-coupled logic 
technology in a product that includes 
many architectural innovations. 

The Cydra 5 is a heterogeneous multi-» 
processor system. The two types of proces¬ 
sors are functionally specialized for the 
different components of the work load 
found in a departmental setting. The 
Cydra 5 numeric processor, based on the 
company’s directed-dataflow architec¬ 
ture, 2 provides consistently high perfor¬ 
mance on a broader class of numerical 
computations than do processors based on 
other architectures. It is aided by the high- 
bandwidth main memory system with its 
stride-insensitive performance. The inter¬ 
active processors offload all nonnumeric 
work from the numeric processor, leaving 
it free to spend all its time on the numeri¬ 
cal application. Lastly, the I/O processors 
permit high-bandwidth I/O transactions 
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The Cydra 5 grew from eight years of 
research and development dating back to 
work done at TRW Array Processors and 
at ESL (a subsidiary of TRW). The poly¬ 
cyclic architecture 3 developed at 
TRW/ESL is a precursor to the directed- 
dataflow architecture developed at 
Cydrome starting in 1984. The common 
theme linking both efforts is the desire to 
support the powerful and elegant dataflow 
model of computation with as simple a 
hardware platform as possible. 

The driving force behind the develop¬ 
ment of the Cydra 5 was the desire for 
increased performance over superminis on 
numerically intensive computations, but 
with the following constraint: The user 
should not have to discard the software, 
the set of algorithms, the training, or the 
techniques acquired over the years. As a 
result, the user would be able to move up 
in performance from the supermini to the 
minisuper in a transparent fashion. This 
transparency is important for a product 
such as the Cydra 5, which is aimed at the 
growth phase of the minisupercomputer 
market. Such a product must cater to a 
broader and less forgiving user group than 
the pioneers and early adopters who pur¬ 
chased first-generation minisupercom- 
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puters. Ideally, a departmental super¬ 
computer will display none of the idiosyn¬ 
crasies of typical supercomputers and 
minisupercomputers and, in fact, will 
project the “feel” of a conventional 
minicomputer, except for its much higher 
performance on numerically intensive 
tasks. 

Cydra 5 system 
architecture 

From the outset we were determined not 
to build an attached processor. The clum¬ 
siness of the host processor/attached 
processor approach leads to difficulty of 
use and loss of performance. The pro¬ 
grammer must manage two computer sys¬ 
tems, each with its own operating system 
and its own separate memory. The pro¬ 
grammer must explicitly manage the 
movement of programs and data back and 
forth between the two systems. Since the 
data transfer path is slow relative to the 
processing speed of both computers, it 
becomes a performance bottleneck. Pro¬ 
gram development tools for the attached 
processor, such as compilers and linkers, 
run on the host. To avoid an unhealthy 
dependence on a single brand of host com¬ 
puter, this software must be maintained on 
multiple brands of host computer. 

A self-sufficient, stand-alone computer 
has none of these problems. On the other 
hand, it assumes the burden of perform¬ 
ing all of the general-purpose, nonnumeric 
work—such as networking, developing 
programs, and running the operating 
system—in addition to the numerically 
intensive jobs for which it was originally 
intended. As we will show later, the trade¬ 
offs made in designing a supercomputer 
and a general-purpose processor are often 
diametrically opposed. As a result, each 
ends up being the most cost effective for 
a different class of jobs. Whereas a super¬ 
computer may have 20 to 30 times the per¬ 
formance of a general-purpose processor 
on numerically intensive tasks, it may have 
only three or four times the performance 
on general-purpose tasks. When price is 
considered as well, the supercomputer 
ends up having poorer cost-performance 
than the general-purpose processor on 
nonnumeric tasks, since its expensive 
floating-point hardware is irrelevant. 

We wanted the Cydra 5 to be not only 
a stand-alone computer but also a depart¬ 
mental supercomputer. By this we mean a 


number of things. It should be affordable 
to a small group or department of 
engineers or scientists, which means an 
entry-level price under $500,000. It should 
be easy to use by such a group and not 
require a “high priesthood” of skilled sys¬ 
tems analysts catering to the idiosyncrasies 
of the machine. Lastly, it should be 
designed to handle all of the work load 
created by a department, not just the 
numerical tasks. As noted, this includes 
tasks such as compiling, text editing, 
executing the operating system kernel, and 
networking—tasks for which a supercom¬ 
puter architecture is not cost effective. 

These goals led to one of the key deci¬ 
sions regarding the Cydra 5: to have a 
numeric processor, highly optimized for 
numerical computing, and a tightly inte¬ 
grated general-purpose subsystem that 
would handle the nonnumeric work load. 
In other words the Cydra 5 was to be a het¬ 
erogeneous multiprocessor, with each 
processor functionally specialized for a 
different, but complementary, class of 
jobs. 

Initially, we planned to acquire a 
general-purpose processor on an original- 
equipment-manufacturer basis and inte¬ 
grate into it a numeric processor of our 
own design. We had determined that we 
needed about 10 million instructions per 
second of computation capability from the 
general-purpose processor to handle the 
I/O load imposed by the application run¬ 
ning on the numeric processor, as well as 
the rest of the general-purpose work load. 
We soon discovered that a superminicom¬ 
puter in this performance range would 
itself have a list price of about 
$500,000—the targeted price for the entire 
Cydra 5! We found consistently that lower 
priced general-purpose computation 
engines whose performance and price were 
closer to what we wanted had underdevel¬ 
oped I/O capability by departmental 
supercomputer standards. This situation 
remains unchanged, if you examine the 
current crop of workstations and super¬ 
workstations. The only workable scheme 
that met both our cost and performance 
constraints was to design our own general- 
purpose subsystem consisting of multiple 
microprocessor-based processors. 

Following a careful evaluation, we 
chose the as yet unannounced Motorola 
68020 microprocessor. The various RISC 
(reduced instruction set computer) 
microprocessors were only on the drawing 
boards at the time. Around the 16-MHz 


68020 we designed a fast interactive 
processor incorporating a 16-Kbyte, zero- 
wait-state cache. A scheme developed by 
two of the authors 4 maintained cache 
coherency in this multiprocessor envi¬ 
ronment. 

We could not afford to develop an oper¬ 
ating system from scratch, so we selected 
Unix, the only nonproprietary operating 
system available. Every workstation and 
minisupercomputer vendor has had to 
make the same choice for the same reason. 
As a result, Unix has become the de facto 
standard operating system for the 
engineering and scientific community. The 
more difficult choice was between the two 
competing flavors of Unix: Berkeley 4.2 
and AT&T System V. Although Berkeley 
4.2 was clearly dominant in 1984-85, we 
believed that with the addition of virtual 
memory and networking, and with 
AT&T’s more aggressive support, System 
V would pull ahead by the time Cydra 5 
was introduced. Accordingly, we took a 
deep breath and jumped on the System V 
bandwagon. 

Although Cydrix, Cydrome’s imple¬ 
mentation of Unix, complies with the 
System V interface definition, it does con¬ 
tain a number of extensions, primarily 
for performance reasons. For use with a 
supercomputer, Unix is a rather low- 
performance, uniprocessor operating sys¬ 
tem. We rewrote the kernel significantly to 
symmetrically (not in a master-slave fash¬ 
ion) distribute it over multiple interactive 
processors so that one or more processors 
could be simultaneously executing in ker¬ 
nel mode. This allowed us to bring the 
aggregate computing capability of multi¬ 
ple processors to bear on the task of sup¬ 
porting the I/O for the numeric processor 
application. The file and I/O systems also 
received numerous enhancements. 

As a consequence of this series of design 
decisions, the Cydra 5 Departmental 
Supercomputer is two computers in one: 
a numeric processor that is the functional 
equivalent of other minisupercomputers, 
and a general-purpose multiprocessor that 
plays the role of a front-end system (Fig¬ 
ure 1). However, these two subsystems are 
very tightly integrated. They share the 
same memory system and peripherals and 
are managed by the same operating sys¬ 
tem. Because of this, the Cydra 5 with 
Cydrix presents the illusion of a simple 
uniprocessor system to the user who does 
not wish to be bothered with what is inside 
the black box. 
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Single contiguous address space 



Structural analysis 
Fluid dynamics 
Computational chemistry 
Seismic processing 
Image processing 


Operating system kernel 
File I/O 
Networking 
Compilation 
Text editing 


Figure 1. The Cydra 5 heterogeneous multiprocessor. The general-purpose subsystem consists of up to six interactive proces¬ 
sors, up to 64 Mbytes of support memory, one or two I/O processors, and the service processor/system console connected 
over a I00-Mbyte/s system bus. Each I/O processor handles up to three VME buses, to which the peripheral controllers are 
attached. Also connected to the system bus, via a 100-Mbyte/s port, is the pseudorandomly interleaved main memory. The 
numeric processor has three dedicated ports into the main memory, each providing 100-Mbyte/s bandwidth. One of these is 
for instructions; the other two are for data. The main memory and support memory share a common address space and are 
both accessible from any processor. 


The directed-dataflow 
architecture 

Assuming the use of the fastest reason¬ 
able technology, any further increase in 
performance requires the effective exploi¬ 
tation of parallelism in one form or 
another. 

Fine-grained versus coarse-grained par¬ 
allelism. There are two major forms of 
parallelism: coarse-grained and fine¬ 
grained. Coarse-grained parallelism, 
popularly referred to as parallel process¬ 
ing, means multiple processes running on 
multiple processors in a cooperative fash¬ 


ion to perform the job of a single program. 
In contrast, fine-grained parallelism exists 
within a process at the level of the individ¬ 
ual operations (such as adds and multi¬ 
plies) that constitute the program. Vector, 
SIMD (single-instruction, multiple-data), 
and the attached-processor, or VL1W 
(very long instruction word), architectures 
are examples of architectures that use fine¬ 
grained parallelism. 

Coarse-grained parallelism is com¬ 
plementary to fine-grained parallelism in 
that they can be used in conjunction. How¬ 
ever, coarse-grained parallelism is not user 
transparent, since state-of-the-art com¬ 
pilers cannot, except in limited situations, 
take a sequential program written in a lan¬ 


guage such as Fortran and automatically 
partition it into multiple parallel processes. 
The user must explicitly restructure the 
program to capitalize on this type of par¬ 
allelism. Since this did not satisfy our 
criteria for ease of use, we focused on the 
exploitation of fine-grained parallelism. 

A bottom-up perspective. The final 
objective is to minimize the execution time 
of any given program. We can express this 
execution time T as 

T=NxCxS 

where Nis the total number of instructions 
that must be executed, C is the average 
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Figure 2. (a) Generic supercomputer data paths, (b) Generic directed-dataflow- 
processor data paths. Each row of cross-point register files in the context register 
matrix can be written into by only a single functional unit, and all register files in a 
single row have identical contents. Since each of the register files in a row can be 
read in parallel, each row is logically equivalent to a single multiported register file 
capable of one write and multiple reads per cycle. Each of the cross-point register 
files can be written to by only a single functional unit and can be read by only a sin¬ 
gle input of a single functional unit—the one associated with that column of cross- 
point register files. This, along with the property that each register file is capable of 
one read and one write each cycle, guarantees conflict-free access to the context 
registers for every functional unit for inputs as well as outputs. 


number of processor cycles per instruc¬ 
tion, and S is the number of seconds per 
processor cycle. To a first approximation, 
N, C, and S are affected primarily by the 
compiler’s optimization capability, the 
instruction set architecture, and the imple¬ 
mentation technology, respectively. How¬ 
ever, the picture is more complicated, and 
decisions that decrease one factor may end 
up increasing another. 

The techniques used to minimize Thave 
been many and varied. For general- 
purpose processors, the traditional 
approach was to reduce Nat the expense 
of a smaller increase in C. The general 
thrust was to better utilize the micro¬ 
parallelism present in horizontally 
microcoded machines by defining more 
complex instructions with more internal 
micro-parallelism in the hope that N would 
decrease more sharply than C would 
increase. This approach is now termed 
CISC (complex instruction set computer). 
By contrast, the RISC approach focuses 
on the use of very simple, hardwired, pipe¬ 
lined instructions exclusively to reduce C 
and S. The resulting increase in N is 
minimized by the use of code optimization 
techniques in the compiler for an overall 
reduction in T. Although both approaches 
have been successful at different times and 
under different circumstances, they are 
not sufficient to meet the performance 
objectives of supercomputers. 

The emphasis in supercomputers is on 
execution of arithmetic (particularly 
floating-point) operations. The starting 
point for all supercomputer architectures 
is multiple, pipelined, floating-point func¬ 
tional units, in addition to any needed for 
integer operations and memory accesses. 
The fundamental objective is to keep them 
as busy as possible. Assuming this will be 
achieved, the hardware must be equipped 
to provide two input operands per func¬ 
tional unit and to accept one result per 
functional unit per cycle. Furthermore, 
since the results of one operation will be 
required as inputs to subsequent opera¬ 
tions, some form of interconnection is 
needed between the result and input buses. 
Finally, since results are not always used 
immediately after generation, storage in 
the form of one or more register files is 
needed. Figure 2a shows the data paths of 
a generic supercomputer. The details, of 
course, vary from one machine to the next; 
the number and types of functional units, 
the number of register files, and the struc¬ 
ture of the interconnect can all be 
different. 

Interesting and rather fundamental 


differences exist between the data paths of 
a scalar processor and those of a super¬ 
computer. In the scalar processor the crit¬ 
ical data paths consist of the circuit from 
the general-purpose registers (GPRs), 


through the integer arithmetic-logic unit or 
the cache, and back to the GPRs. This 
makes it relatively easy to keep the physi¬ 
cal distances small, the pipelining moder¬ 
ate, and the cycle time short. In contrast. 
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critical data paths in a supercomputer 
must include multiple floating-point pipe¬ 
lines, large numbers of register files, and 
a complex interconnect. The physical dis¬ 
tances are necessarily larger, and there are 
more electrical loads to be driven on each 
bus. Both factors cause a larger fraction of 
the cycle to be consumed in merely trans¬ 
ferring data from one point to another. 
This makes it necessary to increase the 
depth of pipelining to avoid compromis¬ 
ing the cycle time. Thus the trade-off is 
short pipeline latencies and better sequen¬ 
tial performance versus multiple, deep 
pipelines and better parallel performance. 

All the hardware in a supercomputer 
can be justified only if it is kept well uti¬ 
lized. But keeping all these pipelines busy 
requires that multiple operations be issued 
(as opposed to being in execution) at every 
cycle. This is impossible in conventional 
scalar architectures, since a maximum of 
one instruction is issued per cycle. 

Two styles of uniprocessor architecture 
have been developed to circumvent this 
bottleneck. One is the vector architecture, 
which attempts to reduce N by the use of 
very complex instructions—vector 
instructions—where a single vector 
instruction does the work of multiple, 
identical scalar operations. Once a few 
vector operations have been launched, 
multiple operations are issued per cycle, 
one each by every vector operation that is 
active. This is philosophically akin to the 
CISC approach and suffers from the stan¬ 
dard problem of complex instructions: 
They work well when they exactly fit the 
job that must be done, but they are useless 
if the task differs even slightly. 

The second, more flexible, approach is 
an architecture in which multiple opera¬ 
tions can be issued in a single instruc¬ 
tion. 2 ' 3,5 ' 7 We can view this as an 
extension of the S1MD architecture; 
instead of the same opcode’s being applied 
to all the pairs of input data, as in SIMD, 
distinct opcodes are used. The formal 
name for such an architecture might be 
single instruction, multiple operation, 
multiple data (SIMOMD), or MultiOp for 
short. Other terms used for such an archi¬ 
tecture include horizontal 3 or very long 
instruction word (VLIW). 5 We can also 
view this as a generalization of the RISC 
architecture, where C is reduced to less 
than 1 by issuing multiple operations (or 
multiple instructions, from a scalar 
processor point of view) per cycle. 

When we started in 1984, MultiOp exe¬ 
cution was used in a number of attached- 
processor products—for example, the 
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FPS-164. 6 Expert programmers were able 
to coax much better sustained perfor¬ 
mance out of these products than could be 
achieved with vector processors having the 
same peak performance. But program¬ 
ming these products for high performance 
had all the complexities associated with 
microprogramming, and some more 
besides. 3,8 The problem resulted from the 
processors’ having been designed entirely 
from a bottom-up, hardware perspective, 
with no thought to how they were to be 
programmed or the obstacles the compiler 
writer would face. While we felt it con¬ 
stituted a step in the right direction, it was 
clear to us that the attached-processor 
architecture was unacceptable. Although 
the general hardware structure of the 
directed-dataflow architecture was dic¬ 
tated by the considerations discussed 
above, the subtler aspects resulted from a 
top-down thought process driven by our 
model of computation. 

The model of computation. Although 
there is a tendency to categorize architec¬ 
tures superficially by their hardware attrib¬ 
utes (pipelined or VLIW, for example), we 
believe that the underlying models of com¬ 
putation and usage are what really matter. 
They determine the context within which 
all of the design decisions are made, and 
they lead to architectural features that, 
though subtle, have a major impact on the 
performance and breadth of a product’s 
applicability. Just as pipelining has been 
applied to a number of quite different 
architectures, so too we find that the abil¬ 
ity to issue multiple operations per cycle 
has been used in at least three types of 
architectures with quite distinct underly¬ 
ing models of computation: the 
microprogrammed attached-processor 
architectures, the VLIW architecture, and 
the directed-dataflow architecture. 

The attached processors borrowed their 
model of computation from micropro¬ 


gramming, where the perspective is very 
bottom-up. In microprogramming, the 
hardware is viewed as a collection of func¬ 
tional units and buses, and the task of the 
microprogrammer is to determine on a 
cycle-by-cycle basis which functional unit 
inputs and outputs connect to which buses. 
The microprogram is generally viewed as 
a sequence of micro-operations, and any 
parallelism needed to exploit a horizontal 
microarchitecture is exposed on a local¬ 
ized, “peephole” basis. Microprograms 
for instruction set interpretation put very 
little emphasis on iterative constructs 
(loops) but a lot on branching. When an 
architecture with these underlying assump¬ 
tions is adopted for numerical processing 
(where the emphasis is on loops), a great 
deal of programming complexity results if 
one wishes to fully exploit the opportuni¬ 
ties for parallelism. 3 

Although the VLIW school of thought, 
too, has its roots in microprogramming, 
the VLIW architecture is properly viewed 
as the logical extension to the scalar RISC 
architecture. The underlying model is one 
of scalar code to be executed, but with 
more than one operation issued per cycle. 
The obstacle to good performance is 
the high frequency of branches in typical 
programs, a problem common to micro¬ 
programming. Consequently, trace 
scheduling, 9 originally developed for 
microprogramming, is used with VLIW 
processors. No special consideration— 
beyond the standard scalar processing 
compiler technique of loop unrolling—is 
given to loops in software, and none what¬ 
soever is given in hardware. Using trace¬ 
scheduling techniques, VLIW can provide 
good speedup on scalar code, and when 
loop unrolling is used, some further 
speedup on iterative computations occurs 
as well. However, given the lack of 
architectural emphasis on loops, VLIW 
does not do as well on vectorizable com¬ 
putations as a vector processor does. 

A supercomputer architecture must do 
well on all types of numerical computation 
it might encounter. This includes straight- 
line or sequential code as well as branch¬ 
ing scalar code; but ciearly of equal or 
greater importance are the iterative con¬ 
structs that constitute the heart of numer¬ 
ical computations. Loops, whether they 
are vectorizable or of the type that con¬ 
tains recurrences, conditional branching, 
or irregular references to memory, must 
get explicit support in the hardware. 
The vector architecture provides hardware 
support, but only for a limited subset of 
loops (those without recurrences and con- 
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ditional branches), reflecting a restrictive 
model of computation. If greater general¬ 
ity is required in the capabilities of the 
architecture, a more general model of 
computation is needed, one that does well 
not only on scalar and vector code like the 
VLIW and vector architectures, respec¬ 
tively, but also on the important class of 
loops that possess parallelism but are not 
vectorizable. 

The dataflow model of computation. 

By making execution of an operation con¬ 
tingent only on its inputs’ being available 
and a functional unit’s being free to exe¬ 
cute the operation, the dataflow model of 
computation exposes and exploits every bit 
of parallelism in the computation regard¬ 
less of its form. 10 Thus it provides an 
excellent basis for a fine-grained parallel 
architecture of broad applicability. 

However, most dataflow research 
assumes that the program is written in a 
dataflow or functional language, whereas 
we had to face the real world of Fortran 
programs. Consequently, we had to base 
our architecture on an extended depen¬ 
dency graph model that included the con¬ 
cept of memory and the corresponding 
memory read and write operations. This, 
in turn, required that the model include the 
concept of antidependency and output 
dependency, 11 in addition to that of data 
dependency. Also, to reflect the rather 
unstructured nature of Fortran control 
constructs, we had to include a richer con¬ 
trol dependency model that went beyond 
nested IF-THEN-ELSEs. Nevertheless, 
the basic philosophy was unchanged; an 
operation is a candidate for execution as 
soon as all its incoming dependencies, of 
all types, have been satisfied. Notwith¬ 
standing the differences between the 
dataflow model of computation and our 
dependency graph model, we will, for the 
sake of convenience, refer to our model of 
computation as a dataflow model. 

The dataflow model has the richness 
needed to yield parallelism on both scalar 
and iterative computation. In scalar code, 
parallelism is restricted by the presence of 
conditional branches and their associated 
control dependencies. Dataflow gets 
around this problem with a mode of oper¬ 
ation known as eager execution, which 
causes operations to be executed before it 
is certain that their execution is needed 
(Figures 3a-3f). This is equivalent to selec¬ 
tively removing certain control depen¬ 
dence arcs to increase the parallelism. 

In iterative computations, dataflow 
dynamically unrolls a loop the same num- 



The dataflow model 
has the richness 
needed to yield 
parallelism on both 
scalar and iterative 
computation. 


ber of times that the loop was supposed to 
be executed. 10 This generates the maxi¬ 
mum parallelism possible, limited only by 
the inherent dependencies in the computa¬ 
tion. (The amount of this parallelism actu¬ 
ally used depends on the number of 
functional units present.) The dataflow 
architecture’s ability to exploit whatever 
parallelism exists in all of these constructs 
makes it the architecture best able to 
exploit all of the fine-grained parallelism 
existing in programs. Furthermore, since 
parallelism is achieved without having to 
make any algorithmic changes to the pro¬ 
gram, the dataflow architecture delivers 
performance increases transparently. For 
these reasons the dataflow architecture 
serves as the basis for the Cydra 5. 

Directed dataflow. The directed- 
dataflow architecture is also significantly 
influenced by another philosophy, one of 
moving complexity and functionality out 
of hardware and into software whenever 
possible; this is the cornerstone of the 
RISC concept as well. The benefits of this 
philosophy are reduced hardware cost and 
often the ability to make better decisions 
at compile time than can be made at run¬ 
time. In the directed-dataflow architec¬ 
ture, the compiler makes most decisions 
regarding the scheduling of operations at 
compile time rather than at runtime—but 
with the objective of emulating faithfully 
the manner in which a hypothetical 
dataflow machine with the same number 
of functional units would execute a partic¬ 
ular program. 

The compiler takes a program and first 
creates the corresponding dataflow graph. 
It then enforces the rules of dataflow exe¬ 
cution, with full knowledge of the execu¬ 
tion latency of each operation, to produce 
a schedule that indicates exactly when and 
where each operation will be performed. 
While scheduling at compile time, the 
compiler can examine the whole program, 


in effect looking forward into the execu¬ 
tion. It thus creates a better schedule than 
might have been possible with runtime 
scheduling. An instruction for the 
directed-dataflow machine consists of a 
time slice out of this schedule, that is, all 
operations that the schedule specifies for 
initiation at the same time. Such an 
instruction causes multiple operations to 
be issued in a single instruction. 

So far, this is the same as any other 
VLIW processor. However, more than the 
ability to issue multiple operations per 
cycle is needed to efficiently support the 
dataflow model of computation in a 
compiler-directed fashion, especially when 
executing loops. Specifically, the directed- 
dataflow architecture provides two 
architectural features: the context register 
matrix and conditional scheduling control. 

The context register matrix. Unlike 
the generic structure shown in Figure 2a, 
a directed-dataflow machine combines 
the register storage and the interconnect 
between functional unit outputs and 
inputs into a single entity known as the 
context register matrix, as shown in Figure 
2b. In general the interconnect structure 
can be viewed as a sparse crossbar with 
certain cross-points absent but with a reg¬ 
ister file at each cross-point present. The 
context register matrix guarantees con¬ 
flict-free access to the context registers 
for every functional unit. This in turn 
guarantees that once a schedule has been 
prepared by the compiler, it will not be ren¬ 
dered infeasible because of contention in 
getting data into or out of the context 
registers, which is one of the fundamental 
problems with the attached-processor 
architectures. 3 

When executing loops in a maximally 
parallel dataflow fashion, each iteration is 
viewed as a distinct computation execut¬ 
ing in parallel with the other iterations. As 
with similar situations where the same 
code is being executed by distinct parallel 
computations, each iteration must have its 
own context so that when two iterations 
apparently refer to the same variable or, 
in this case, the same register (since they 
are both executing the same code), the 
physical locations actually accessed are 
distinct. When concurrent processes are 
forked, this is achieved by providing each 
process with a duplicate name space. In the 
case of recursive invocations of the same 
procedure, this is handled by providing 
separate stack frames. Each invocation’s 
reference to a particular local variable is in 
the context of its own stack frame. Like- 
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300 

400 


T1 - X(l) + X(J) 

IF (K'l.GT.J) GOTO 300 
Y(l) ■ Y(l) +T1 
GOTO 400 
Y(J)-T1-Y(J) 


(a) 


100 tnl-X(l) 
tn2 - X(J) 

T1 — tnl +In2 


200 


400 


tn4 - (tn3.GT.J) 
IF tn4 GOTO 300 
tnS - Y(l) 
tn6-tn5+T1 


Y(l) - tn6 
GOTO 400 
ln7.Y(J) 
InS-TI -tn7 
Y(J)-tn8 


(b) 




Figure 3. (a) A fragment of Fortran code, (b) Expansion of the code into individual operations with a label on the right-hand 
side for each operation. The scalar variables K, /, and J are assumed to be in registers already, (c) Sequential code schedule 
assuming a seven-cycle latency for memory reads and a two-cycle latency for all other operations. The code fragment consists 
of three basic blocks. BB2 and BB3 can be entered from BB1 as well as from elsewhere. A traversal of this code fragment takes 
19 cycles. Note the scheduling of operations in the delay slots of the delayed branch, (d) The dataflow graph for this code frag¬ 
ment. Solid arcs are data dependencies. Dashed arcs are control dependencies that enable or disable operations, depending on 
the Boolean result of the comparison Cl. Note that branch operations have no role in the dataflow model of computation, (e) 
Schedules resulting from the execution of the dataflow graph (assuming the ability to initiate two memory operations and one 
other operation per cycle). Operation A1 from BB1 is initiated in parallel with the execution of either BB2 or BB3. The extent 
of the overlap between the execution of BB1 with the execution of either BB2 or BB3 is determined by the control dependency 
from Cl to R3 or R4, which determines whether BB2 or BB3 should be executed, (f) Eager execution of R3 or R4 results from 
the removal of the control dependency from Cl. Now both R3 and R4 are initiated before it has been determined whether BB2 
or BB3 is to be executed. As a result the total execution time is reduced, (g) Directed-dataflow code that achieves the same 
effect as in (e). Operation A1 has been moved from BB1 into both BB2 and BB3. However, to preserve the original semantics, 
it should be executed only if BB2 or BB3 was entered from BB1. Therefore, both copies of A1 have the predicate correspond¬ 
ing to BB1 even though they are in BB2 and BB3. (h) Directed-dataflow code that performs the eager execution of R3 and R4 
by moving them up into BB1. (They must also be copied into all basic blocks from which they can be entered.) The total execu¬ 
tion time for this fragment of code is now 12 cycles. 
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wise, the maximally parallel execution of 
loop iterations requires that each itera¬ 
tion’s register references be within the con¬ 
text of the corresponding iteration frame, 
that is, a set of registers allocated to a par¬ 
ticular iteration. 

The directed-dataflow architecture has 
the architectural facilities needed to 
dynamically allocate iteration frames at 
runtime and the requisite addressing capa¬ 
bilities to reference registers in both the 
current iteration frame and, in the case of 
recurrences, in previous iteration frames. 
Surprisingly, these architectural facilities 
incur only a modest hardware cost, namely 
the ability to reference the context registers 
with an instruction-specified displacement 
from a base register containing the itera¬ 
tion frame pointer (IFP). Since the IFP is 
decremented each time a new iteration is 
initiated, each iteration of the loop 
accesses a distinct set of physical registers. 
Any result computed during the same or 
a previous iteration can be accessed by 
using the appropriate displacement from 
the current value of the IFP. This displace¬ 
ment can be computed by the compiler, 
since it knows the difference between the 
current value of the IFP and the value at 
the time the result was generated, as well 
as the original displacement from that 
value of the IFP. Some interesting regis¬ 
ter allocation techniques in the compiler 
are central to the efficient use of the con¬ 
text registers, but they are beyond the 
scope of this article and will be reported 
elsewhere. 

Conditional scheduling control. In a 

sequential model of computation, the pro¬ 
gram consists of a set of basic blocks, each 
containing a list of instructions. Only one 
basic block is active at any one time. The 
equivalent dataflow view is that a program 
consists of a set of basic blocks, each con¬ 
sisting of a dependency graph of opera¬ 
tions executed in a parallel fashion. 
Conceptually, any given operation has two 
types of incoming dependencies: the data 
(input operands) dependencies, which 
determine when the operation can be 
issued, and a control dependency from an 
operation—in another basic block—that 
computes the predicate. The predicate 
determines whether the operations in a 
basic block are to be issued at all. The 
predicate is true and the operations are 
issued if and only if control would have 
flowed to that basic block in the cor¬ 
responding sequential program. 

Since an operation can be executed as 
soon as its data and control dependencies 
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Figure 4. Relationship between various uniprocessor architectures. On vectorizable 
loops, directed-dataflow is slightly better than the vector architecture, which is bet¬ 
ter than VLIW, which in turn is better than the scalar architecture. On sequential 
code, directed dataflow is at least as good as VLIW, which is better than both the 
vector and scalar architectures. On nonvectorizable loops, directed dataflow is sig¬ 
nificantly better than all three architectures. 


have been satisfied, it is possible to have 
multiple basic blocks active at the same 
time (Figures 3e and 30, particularly in the 
case of loops, whether they have condi¬ 
tional branching within the body of the 
loop or not. This generates the desired par¬ 
allelism but is possible only because 
dataflow can have multiple loci of control 
active simultaneously. The directed- 
dataflow architecture has the goal of 
achieving the same effect as dataflow, but 
with a single locus of control. This is 
achieved by including in each basic block 
operations from other basic blocks that 
should be executing in parallel (Figures 3g 
and 3h). This is a form of code motion, in 
this case for enhancing the parallelism in 
the program. 

An explicit predicate is unnecessary in 
the sequential model of computation, 
since all operations in a single basic block, 
by definition, have the same predicate. 
This predicate is implied by the fact that 
the program branched to this basic block; 
that is, it decided that this basic block was 
to be executed. Thus the predicate’s being 
true and the flow of control’s arriving at 
the basic block are synonymous. 

But these two concepts must be decou¬ 
pled in the case of directed dataflow, since 
a basic block can contain operations that 


in the sequential program would have been 
in another basic block, and thus under a 
different predicate. Consequently, each 
operation is provided with a third input— 
the predicate—in addition to the two nor¬ 
mal ones. An operation is issued only if 
control flows to its basic block and the 
predicate is true. The predicate input speci¬ 
fier specifies a register in a Boolean regis¬ 
ter file, which, for historical reasons, is 
termed the iteration control register (ICR) 
file. Boolean values, which result from 
compare operations, may be transferred 
into the ICR. In loops, each iteration 
generates predicates corresponding to the 
conditional branches (including the loop 
exit conditional) within the loop body. 
Therefore, the ICR too must support the 
capability for allocating iteration frames. 

With hardware support in the form of 
the context register matrix and conditional 
scheduling control, the compiler can 
generate code for the directed-dataflow 
machine that retains the parallelism of the 
dataflow architecture. At the same time, 
it capitalizes on the efficiencies of moving 
scheduling from runtime to compile time. 
It is this architectural support for the 
dataflow model of computation that sets 
directed dataflow apart from other VLIW 
architectures. 


Comparison with other fine-grained 
architectures. Figure 4 shows the relation¬ 
ship between various architectures that 
exploit fine-grained parallelism. It uses 
two criteria: performance on iterative 
computations and performance on scalar 
code. At opposite ends of the spectrum are 
the (dynamically scheduled) dataflow 
architecture, which can exploit all the par¬ 
allelism, and the scalar architecture, which 
exploits none of it. The vector architecture 
is better than the scalar on the restricted 
class of vectorizable computations, but no 
better on scalar code. The VLIW architec¬ 
ture does better than the scalar architecture 
on scalar code and much better on iterative 
computations, but it does not do as well as 
the vector architecture on vectorizable 
loops. This is because the loop-unrolling 
techniques that it uses can yield only short 
vector performance levels. On scalar codes 
the directed-dataflow architecture is at 
least as good as the VLIW architecture and 
better than the vector architecture. It is 
slightly better than the vector architecture 
on vectorizable loops, since strip mining 
(Figure 5) is unnecessary, and it is far bet¬ 
ter on nonvectorizable loops. Directed 
dataflow, as a result of its architectural 
support for dataflow, is better than the 
VLIW architecture on iterative compu¬ 
tations. 


Numeric processor 
decisions and trade-offs 

Technology selection. The choice of 
implementation technology was perhaps 
the most important decision we had to 
make, since it fundamentally affected all 
other decisions and trade-offs. Our back- 
of-the-envelope calculations indicated 
that the same architecture could be imple¬ 
mented in TTL/CMOS at two-fifths 
the performance of an emitter-coupled 
logic (ECL) implementation and two- 
thirds the cost (a 100-nanosecond rather 
than a 40-nanosecond cycle). If cost and 
performance had been the only consider¬ 
ations, it would have been a simple deci¬ 
sion, since our corporate objective was to 
serve the high end of the departmental 
supercomputer market. However, we real¬ 
ized that opting for an ECL implementa¬ 
tion would preclude the use of VLSI 
floating-point chips such as the Weitek 
chips and that it would require the design 
of more logic and more boards, as well as 
more development time—hence, more 
nonrecurring expenditures. 
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Also, some people at that time believed 
ECL was a doomed technology, that 
CMOS would catch up in performance— 
and at a fraction of the cost. Although this 
belief was, and still is, incorrect, there was 
tremendous pressure from the investment 
community to build a TTL/CMOS prod¬ 
uct and even to discard some of the func¬ 
tionality and build a subset of what we 
were planning. However, we were con¬ 
vinced that the low end of the market 
would be very crowded with minisuper¬ 
computers and array processor products. 
(This has, in fact, come to pass, except that 
superworkstations have replaced array 
processors as the threat at the low end.) We 
wanted to be above the general melee, so 
we decided to stick with our business plan 
and implement an ECL product. We now 
feel vindicated in that decision, since more 
and more computer vendors are currently 
moving to this technology. At a 
40-nanosecond cycle time, this yielded a 
processor with a peak performance of 25 
million floating-point operations per sec¬ 
ond (Mflops) with 64-bit operands, 50 
Mflops with 32-bit operands, and 175 mil¬ 
lion operations per second overall. 

In the interest of reducing the nonrecur¬ 
ring development costs and the develop¬ 
ment risk, we made another important 
decision: By and large, we would use off- 
the-shelf ECL components. Gate arrays 
would be used only in certain 
performance-critical parts of the design, 
and even so, not for control logic. Since 
this was the first implementation of a 
directed-dataflow processor, the decision, 
even in retrospect, was correct. But it had 
many unpleasant consequences. The 1985 
vintage of standard ECL logic was at a 
very low level of integration. This meant 
that the numeric processor would occupy 
a lot of real estate. Since manufacturing 
considerations limited us to boards of 
roughly 18 inches on a side, the numeric 
processor would have to be spread out 
over a large number of boards. This led to 
a snowballing effect; large amounts of 
buffer logic were required to drive signals 
between the many boards. This in turn 
increased the total amount of logic even 
further. If we had had the option of imple¬ 
menting the numeric processor entirely 
with gate arrays, we could have reduced its 
size by a factor of three or four. 

Number of functional units. Our per¬ 
formance goal was to be able to initiate one 
floating-point add and one floating-point 
multiply every 40-nanosecond cycle, using 
two separate pipelined functional units. 


Additional functional units were required 
to support these two floating-point pipe¬ 
lines. The first issue was the number of 
ports to memory that were needed. Our 
thinking here was influenced by the fact 
that our model of computation was 
dataflow and not vectors. We viewed the 
entire body of the loop as a single entity 
rather than as a number of separate vector 
operations. Thus we required memory 
reads and writes only for the array inputs 
and outputs, not for the scalar tem¬ 
poraries, which on a vector machine would 
be converted to vector temporaries. This 
reduced the relative number of memory 
operations needed on our machine (Figure 
5). 

Our program statistics indicated that 
within innermost loops the balance 
between memory bandwidth and floating¬ 
point computation capability was between 
one and three memory operations per pair 
of floating-point operations. Although 
certain important computations such as 
SAXPY (the addition of one vector to 
another one that has been multiplied by a 
scalar) require one and a half memory 
operations per floating-point operation, 
we felt that this was an expensive luxury in 
hardware and that the need was not 
statistically frequent enough to warrant 
the expense. Also, half a memory opera¬ 
tion per floating-point operation seemed 
entirely inadequate. So, given the existence 
of two floating-point functional units, we 
decided to have two ports to memory. 
Since it is necessary to compute an address 
for each memory operation, typically to 
increment an index into an array, this 
implied the presence of two address 
(unsigned integer) adders. Also, to facili¬ 
tate dope vector calculations for random 
references into multidimensional arrays, 
we provided an address multiplier. 

Within loops there are also, typically, a 
certain number of integer operations. 
Since we did not wish to have these oper¬ 
ations steal cycles from the floating-point 
units, we added an integer functional unit. 
This left us with a grand total of eight pipe¬ 
lined functional units. A subsequent crisis 
caused by the burgeoning amount of logic 
required a reduction in the size of the 
numeric processor. As a result of this exer¬ 
cise, we eliminated the integer unit and the 
address multiply unit as separate pipelines 
and merged them with the floating-point 
adder and address adder units, respec¬ 
tively. 

Very early in the project, we constructed 
a prototype scheduler that would generate 
schedules for programs written in a low- 


Y(l) = X(l) - Q 
X(l) = Q + V(l) * X(l) 
INDDO 


Q = U(l) * Y(l) 
Y(l) = X(l) - Q 

. isisvy 


DO I = 1, N, 64 
DO J = 1,1+63 
Q = U(l) * Y(l) 
Y(l) = X(l) - Q 

Mivy 

ENDDO 

ENDDO 


Figure 5. (a) Fortran code for a loop. 

(b) Fortran loop rewritten with just one 
floating-point operation per statement. 
Each statement would become a vector 
floating-point operation. Using registers 
in a scalar machine would result in only 
six memory operations (four reads and 
two writes) per iteration. A memory-to- 
memory vector processor would require 
12 memory operations per iteration 
(two reads and one write per statement). 

(c) Using vector registers can bring the 
memory operations back down to six 
per iteration, but because of the finite 
length of the vector register (assumed to 
be 64 in this example), strip mining 
must be used. The loop is transformed 
into a doubly nested loop. The inner 
loop handles 64 long chunks of the vec¬ 
tor; the outer loop sequences through 
all chunks that make up the vector. (For 
simplicity, N is assumed to be a multi¬ 
ple of 64.) Strip mining limits the length 
of vector operations to no more than 
the vector register length, thus reducing 
performance. In the directed-dataflow 
architecture, since registers are continu¬ 
ously deallocated from iterations that 
have completed and allocated to new 
iterations, the number of memory oper¬ 
ations per iteration is six, yet there is no 
restriction on the length of the vector 
operation. 
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Figure 6. Major numeric processor data paths. The numeric processor E-unit con¬ 
tains two major parts: the data cluster and the address cluster. The data cluster 
consists of four functional-unit pipelines interconnected by the data context register 
matrix. These four pipelines are (1) the floating-point adder/integer ALU (four¬ 
cycle latency), (2) the floating-point/integer multiplier (five-cycle latency) and 
divider, as well as the square-root unit, (3) memory data port 1 (17-cycle latency), 
and (4) memory data port 2 (17-cycle latency). The address cluster consists of two 
address adder pipelines (three-cycle latency) interconnected by the address context 
register matrix. In addition, the first pipeline provides a bit-reverse capability, 
while the second provides an integer multiply capability. The context register 


level dependency graph language. This 
scheduler worked in a table-driven man¬ 
ner, using for this purpose a machine 
description file. By modifying this 
machine description file, we were able to 
estimate the relative performance of the 
numeric processor while varying the num¬ 
ber of pipelines, the depth of the pipelines, 
and the assignment of opcodes to func¬ 
tional units. One of the alternatives we 
experimented with was the number of 
floating-point functional units, bearing in 
mind that computational balance required 
a memory port and an address unit for 
each floating-point unit. We found that 
the increase in performance with the num¬ 
ber of floating-point units was quite sub- 
linear, while the increase in cost and 
complexity was most definitely super- 
linear. We opted, therefore, to stay with 
two floating-point units and to design 
them to run as fast as possible instead of 
providing many slow units. Given a certain 
target performance level, the compiler 
needs to find less parallelism in the pro¬ 
gram in a processor with a few fast units 
than in one with many slow units. 

At this point we had six pipelined func¬ 
tional units (including the two memory 
ports), each requiring two input operands 
and generating a result. Complete connec¬ 
tivity between all outputs and all inputs 
would have required a 6 x 12 crossbar with 
a register file at each cross-point. This was 
infeasible from an implementation view¬ 
point. And yet, with our understanding of 
the problems of programming Floating 
Point Systems’ AP-120B, we were unwill¬ 
ing to eliminate cross-points in an ad hoc 
manner. Some underlying scheme having 
conceptual integrity and relevance from 
the viewpoint of the compiler writer was 
essential. 

We partitioned the functional units 
on the basis of data versus addresses, 
placing the two floating-point units, the 
integer unit, and the two memory ports in 
the data cluster and the remaining func¬ 
tional units in the address cluster. This 
immediately reduced the number of cross- 
points by half. The final structure of the 
numeric processor’s data paths is shown in 
Figure 6. 

Another major constraint, especially in 
the context of an interconnection-rich 
architecture such as this, was the amount 
of board I/O. Obviously, the choice of 
data path width had a major impact on the 
number of signals crossing board bound¬ 
aries. With 32-bit data paths we found 
ourselves up against a wall even with the 
use of fairly aggressive connector technol¬ 


ogy. A move to 64-bit data paths would 
have required the use of exotic and expen¬ 
sive connectors. The rule of thumb we had 
developed indicated that 64-bit data paths 
instead of 32-bit data paths would increase 
64-bit performance by 50 percent and 
32-bit performance not at all. Discretion 
being the better part of valor, we elected 
to use 32-bit data paths. 


Register storage. The context register 
matrix provides the architectural facilities 
needed to dynamically allocate iteration 
frames at runtime. Since each iteration 
initiated is allocated an iteration frame, 
and since the total number of registers in 
the context register matrix is Fixed, the iter¬ 
ation frames for past iterations must be 
deallocated at the same rate that new ones 
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matrix (CRM) provides simultaneous, conflict-free access to all functional-unit 
inputs and outputs. Also, by virtue of the iteration frame pointer relative address¬ 
ing into it, the CRM supports overlapped execution of loops. Each functional unit 
has three inputs. Two of these are the conventional operand inputs sourced by 
either the CRM or the general-purpose registers (GPR). The third input is a 
Boolean value from the iteration control register (ICR) used to conditionally con¬ 
trol the issuance of operations. The output of each functional unit can go either to 
its row in the CRM or to the GPR. Like the CRM, the GPR and ICR consist of as 
many carbon-copy register files as there are inputs that can source them. 


are allocated. While this is exactly what is 
desired for loop variants (values computed 
by each iteration), it poses a problem for 
loop-invariant values that are used, but 
never computed, within the loop. Unless 
they are continuously copied from one 
iteration frame to the next, they will be 
overwritten. To avoid the significant over¬ 
head of copying loop invariants, we 


provided a register file that is global to all 
iterations and does not possess the itera¬ 
tion frame capabilities. With considerable 
originality, we called this the general- 
purpose register file. In a single cycle it can 
be read by any number of functional unit 
input ports simultaneously and at distinct 
locations, just like a row in the context reg¬ 
ister matrix, and it can be written to by the 


output port of any functional unit, but 
only one at a time. 

One of the more ad hoc decisions we 
made was choosing the number of registers 
per register file. The problem we faced was 
a lack of directly relevant statistics on the 
effect of this parameter on performance in 
the context of a directed-dataflow style of 
execution. So we plucked the decision out 
of thin air. Our collective intuition told us 
that 32 registers per register file was too 
few, and 128 registers looked difficult 
from an implementation viewpoint. Thus 
we settled on 64 registers per register file. 
Comforted by the lack of alternatives, we 
moved on. 

The capacity of the iteration control reg¬ 
ister (ICR) was determined by two oppos¬ 
ing considerations. Since each predicate 
would be used as input to operations 
scheduled to execute at times separated by 
rather long intervals, we expected the life¬ 
time of these values to be long. This 
implied more capacity in the ICR than in 
the register files in the context register 
matrix. On the other hand, the number of 
bits available in the instruction format to 
address the ICR was at a premium. We 
finally decided to provide an ICR capac¬ 
ity of 128. 

Opcode repertoire. The basic philoso¬ 
phy in the directed-dataflow architecture 
is to work with atomic operations that can 
be scheduled with maximum flexibility. 
So, we have no operations of the CISC 
type that read from memory (two oper¬ 
ands), perform an operation, and write the 
result back to memory. To our way of 
thinking, this is actually four different 
operations packaged together, usurping 
the compiler’s ability to achieve optimal 
scheduling. Except for the memory Read 
and Write opcode class, no other opcodes 
access memory. Their inputs and outputs 
are predominantly either the context reg¬ 
ister matrix or the GPR file. Also, with a 
few exceptions, the opcode repertoire is 
the normal set of integer, logical, floating¬ 
point, and memory operations. The few 
exceptions relate to supporting the 
directed-dataflow model of computation. 
The opcode repertoire reflects the numer¬ 
ical bias; while there is extensive support 
for floating-point operations, there is none 
for binary-coded decimal arithmetic or 
string operations. Except in the case of 
(bitwise) logical operations, where it would 
be redundant, opcodes are provided for 
both single-precision (32-bit) and double¬ 
precision (64-bit) operations. The data 
types supported by the execution unit 
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hardware are 32-bit and 64-bit IEEE float¬ 
ing point, 32-bit and 64-bit 2’s comple¬ 
ment integers, 32-bit unsigned in the 
address cluster, and 32-bit logical. 

The data paths, as well as the registers 
in the numeric processor, are 32 bits wide. 
We believed that register allocation in the 
compiler would be simplified if the two 
halves of a 64-bit datum could be indepen¬ 
dently assigned to unrelated registers. This 
meant we would need four source-register 
specifiers and two destination-register 
specifiers for a 64-bit operation. Since we 
have 32-bit data paths, it takes two cycles 
to provide the input operands for a 64-bit 
operation. Consequently, in the schedule 
as well as in the code, no operation can 
immediately follow a 64-bit operation. We 
decided to use this dead cycle to provide 
two source specifiers and one destination 
specifier. The rest of the specifiers are 
provided in the previous instruction (the 
one initiating the 64-bit operation). 

The memory opcode repertoire includes 
opcodes to read and write 32-, 16-, and 
8-bit data. The 16-bit reads and writes have 
signed as well as unsigned versions. With 
the 16-bit reads, this determines whether 
the 16-bit datum is interpreted as a signed 
or an unsigned integer. This in turn deter¬ 
mines whether the sign is extended or zeros 
are inserted in the high-order 16 bits of the 
32-bit destination register. All integer 
arithmetic is carried out thereafter on 
32-bit data. When a 16-bit datum is writ¬ 
ten back to memory, use of the signed or 
unsigned opcode determines whether or 
not the 32-bit quantity in the register can 
be treated as a 16-bit quantity without 
overflow. If an overflow occurs, it is 
reported at the time of the 16-bit write. The 
32-bit Exchange Read opcode exchanges 
the contents of the specified register and 
memory location as an indivisible opera¬ 
tion. This opcode supports synchroniza¬ 
tion between asynchronous parallel 
processes. 

Although the opcode repertoire is iden¬ 
tical for both memory ports, an asym¬ 
metry results because of insufficient 
instruction word bits to go around. Mem¬ 
ory port 1 can specify the memory address 
as an instruction-specified displacement 
off a base register. Memory port 2 cannot 
specify a displacement. 

The numeric processor has two special 
opcodes to support loop execution: brtop 
and nexti. Two types of actions must be 
performed to control loops. One is to 
determine whether another iteration is to 
be executed and, if so, to allocate a new 
iteration frame. This is done by the nexti 


opcode. The other action is to actually 
branch back to the top of the loop if 
another iteration is to be executed. The 
brtop opcode does this in addition to 
everything the nexti opcode does. If it were 
not for the long, three-cycle branch 
latency, the nexti operation would be 
unnecessary. But in certain very small 
loops, the interval between the initiation 
of successive iterations can be less than the 
branch latency. If not for the nexti opcode, 
this would pose an unnecessary upper 
bound on performance of one iteration 
every three cycles. But with the nexti 
opcode, it is possible to initiate new itera¬ 
tions in the delay slots of the brtop opera¬ 
tion. This allows up to three iterations per 
brtop executed and the initiation of up to 
one new iteration every cycle. 

Instruction format. The data paths of 
the numeric processor can initiate six oper¬ 
ations every cycle. Therefore, the MultiOp 
instruction format (Figure 7a) must be able 
to issue six operations on the six functional 
units, plus an additional one to control the 
instruction unit and other miscellaneous 
operations. A MultiOp instruction con¬ 
sists of seven partitions, one for each oper¬ 
ation; each instruction looks like a 
conventional RISC instruction except for 
the existence of a predicate specifier. The 
typical format for each operation partition 
consists of an opcode, two source-register 
specifiers, one destination-register speci¬ 
fier, and one predicate-register specifier 
(Figure 7b). 

The data cluster has four context regis¬ 
ter matrix rows and the GPR to select 
among for a source, and one row plus the 
GPR to select between for the destination. 
Similarly, the address cluster has two con¬ 
text register matrix rows and the GPR to 
select among for a source, and one row 
plus the GPR to select between for the des¬ 
tination. Assuming an average of five or 
six bits in the opcode field, 64 registers in 
each register file, and 128 locations in the 
ICR, this implies roughly 40 bits per oper¬ 
ation partition or 240 bits per instruction. 
To avoid the need for complex instruction 
fetch logic, we were determined that the 
instruction word width would be a power 
of 2. Thus 256 bits appeared to be a 
reasonable target. Furthermore, since an 
instruction word width of 512 bits would 
have caused a considerable increase in the 
cost and complexity of the instruction 
unit, 256 bits seemed the only option avail¬ 
able. This rigid constraint required a num¬ 
ber of trade-offs, which are discussed 
below. 


In portions of the program where signif¬ 
icant parallelism exists, including but not 
limited to innermost loops, the MultiOp 
format is very effective. However, because 
it gobbles up 32 bytes every 40 nanose¬ 
conds, we were worried about the effect on 
instruction cache performance and capac¬ 
ity should the MultiOp format be used 
indiscriminately, even in portions of the 
code where little parallelism exists. With 
this in mind, we created the UniOp instruc¬ 
tion format (Figure 7c), which allows only 
a single operation to be initiated per 
instruction, making it possible to fit mul¬ 
tiple UniOp instructions in each 256-bit 
container. The opcode repertoire available 
in the UniOp format is identical to that in 
the MultiOp format. While executing 
UniOp instructions, the numeric processor 
is similar to other scalar architectures that 
have no pipeline interlocks in hardware. 

The UniOp instruction must contain not 
only all the information contained in the 
corresponding MultiOp partition, but also 
a few additional bits to indicate which 
functional unit is being tasked. The longest 
partition in the MultiOp format is for 
memory port 1, which contains a literal 
field for specifying an address displace¬ 
ment or a data literal. This partition is 44 
bits long. If each UniOp instruction is at 
least 44 bits, it is possible to fit at most five 
instructions per instruction container, for 
an average instruction width of 51 bits. We 
felt that this would dilate the size of the 
compiled code to an uncomfortable 
extent. As a compromise we decided to 
forgo the predicate capability in UniOp, 
reasoning that the UniOp sections of code 
were not supposed to be performance crit¬ 
ical anyway. Now it was possible to fit six 
UniOp instructions per container. Any 
more than six per container would have 
required us to reduce the 16-bit address 
displacement field size. Since we felt that 
16 bits was barely adequate, we were 
unwilling to reduce it further. The 40-bit 
UniOp format also permitted us to provide 
a 24-bit program address literal. 

The MultiOp format contained 18 con¬ 
text register matrix or GPR specifiers and 
six ICR specifiers. Increasing the number 
of registers per register file from 64 to 128 
would have required 18 additional instruc¬ 
tion bits in MultiOp, which were not avail¬ 
able. This helped us realize that adding 
more registers was not an option. Decreas¬ 
ing the number of ICR locations from 128 
to 64 would have saved six MultiOp 
instruction bits—not enough to make an 
appreciable difference elsewhere. 
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Figure 7. Numeric processor instruction formats, (a) The MultiOp format is 32 bytes long and permits seven operations to be 
issued during each 40-nanosecond cycle, (b) The structure of each partition in the MultiOp format, (c) The UniOp format 
allows six instructions to fit into a 32-byte container. Each instruction can issue only one operation per 40-nanosecond cycle. 


Exception handling. Exceptions and 
interrupts pose a special challenge to 
architectures such as directed dataflow, 
where the execution sequence is so care¬ 
fully and rigidly choreographed. The basic 
problem in handling an exception is sched¬ 
ule tearing , which means the carefully 
crafted computation schedule is being 
drastically altered by inserting the compu¬ 
tation corresponding to the exception han¬ 
dler into the middle of the original 
computation. The compiler-generated 
schedule is literally torn apart to allow the 


exception handler to execute. This can 
cause two types of problems: first, the con¬ 
flicting usage of scheduled resources, and 
second, the violation of implicit dependen¬ 
cies between operations. 

Avoidance of resource conflicts is 
achieved by flushing all pipelines during 
transition between the user program and 
the exception handler. This is done by 
aborting operations in progress, by allow¬ 
ing them to execute to completion, or by 
saving and subsequently restoring their 
state of partial execution. Conceptually, 


the last alternative is the simplest. It is also 
the costliest in terms of hardware require¬ 
ments, so it is the solution of last resort. 
Aborting operations is extremely compli¬ 
cated, since those operations will need to 
be reissued after exception handling, 
which means the program counter and the 
processor state must be backed up. Allow¬ 
ing operations that have been issued to go 
to completion is the best technique over¬ 
all, except in certain cases. Clearly, if the 
exception is due to an operand page fault 
occurring in the course of executing a 


January 1989 


25 













































memory operation, the memory operation 
cannot complete until the page fault excep¬ 
tion has been handled and the page has 
been brought into physical memory. In 
this case the best alternative is to save the 
state of that portion of the memory pipe¬ 
line extending through the virtual address 
translation and to restore it after exception 
handling. 

If special care is not taken, schedule 
tearing can result in the violation of 
required dependencies between opera¬ 
tions. It can cause an operation scheduled 
to finish after a second one has started to 
actually finish before the second one 
starts. This will lead to incorrect results if 
the first operation writes to the same reg¬ 
ister the second one reads, and if the sec¬ 
ond operation expects to get the contents 
that existed prior to the register’s having 
been overwritten. Such a situation is 
prevented by a compiler convention that 
decrees a register to be “in use” from the 
beginning of the operation that writes to 
it until the latest completion time of all 
operations using that value. With this con¬ 
vention in place, two operations that over¬ 
lap each other’s execution intervals will 
have to use different source and destina¬ 
tion registers, thereby avoiding the 
problem. 

Clearly, handling an exception requires 
that no further instructions (operations) be 
issued once the exception has occurred. 
But this can contradict the strategy of 
executing to completion an operation in 
progress if the information corresponding 
to that operation is distributed across mul¬ 
tiple instructions. This is often the case in 
microprogramming-style architectures, 
where, instead of providing the opcode, 
the source specifiers, and the result speci¬ 
fiers at the same time, the architecture pro¬ 
vides the result specifier many instructions 
later than the opcode, reflecting the time 
when each item of information is actually 
needed. 

The problem is that when the exception 
occurs, not all of the information needed 
by the operation to execute to completion 
has been issued; that is, the operation is in 
a partially issued state. For the operation 
to execute to completion, further instruc¬ 
tions must be issued, which in turn would 
cause further operations to be issued 
whose completion would require the issu¬ 
ance of still more instructions, and so on. 
The only solution would be to issue further 
instructions selectively in a way that would 
prevent the issuance of new operations 
until the operations already in progress 
had received all the information they need 


to execute to completion. After the excep¬ 
tion has been handled, instruction issuance 
would have to begin with the first instruc¬ 
tion initiating an operation that was not 
issued prior to exception handling, while 
taking care to selectively mask out opera¬ 
tions issued previously. Because this is so 
messy, it is highly desirable that all infor¬ 
mation pertaining to a single operation be 
specified at the same time in the same 
instruction. 

In the numeric processor, however, 
double-precision operations are dis¬ 
tributed over two consecutive (in time) 
instructions. Thus, at least to a limited 
extent, the problems described above must 
be dealt with. Two measures accomplish 
this; 

(1) The one instruction issued after the 
exception (since it may contain the 
second half of a double-precision 
operation) must be issued with all 
“new” (that is, single-precision or 
first half of double-precision) oper¬ 
ations disabled. 

(2) The opcode for the second half of a 
double-precision operation should 
be such that in isolation (when 
viewed as a single-precision opera¬ 
tion or the first half of a double¬ 
precision operation) it will be inter¬ 
preted as a no-op. 

The first requirement allows the appropri¬ 
ate functional unit to get the information 
it needs to allow a double-precision oper¬ 
ation issued in the previous cycle to execute 
to completion. The second requirement 
makes it simple to resume issuing instruc¬ 
tions after handling the exception. Since 
they are interpreted as no-ops, second 
halves of double-precision operations will 
automatically “mask” themselves out. 

However, the first requirement cannot 
be met when the second half of a double¬ 
precision operation lies in a different page 
from that in which the first half lies and if 
the instruction fetch for the second half 
generates a page fault. In this case the 
double-precision operation must be 
aborted and restarted by resuming instruc¬ 
tion issuance with the last instruction actu¬ 
ally issued. For this to be possible, the 
inputs to operations issued in the instruc¬ 
tion to be restarted must not have been 
modified. This will be true if another com¬ 
piler convention is observed: The registers 
that are sources to an operation in a par¬ 
ticular instruction should be viewed as 
“busy” through the end of the issuance of 
all double-precision operations whose first 
halves are in the same instruction. 


PC history queue. One consequence of 
very deep pipelines is that between the issu¬ 
ance of an operation and its completion, 
it is possible to have executed multiple 
branch operations. If an operation gener¬ 
ates an exception, the deep pipelining 
makes it extremely difficult for a debug¬ 
ger to figure out the program counter value 
for the instruction that initiated the 
offending operation. To solve this prob¬ 
lem, we included a circular 256-entry PC 
history queue (PCHQ). During normal 
operation the current PC value is written 
into the PCHQ on every cycle. The state 
of the PCHQ is frozen when an exception 
occurs. Knowing the latency of the offend¬ 
ing operation, the debugger can index back 
into the PCHQ by that amount to locate 
the PC value for the corresponding 
instruction. 

Although this was the original motiva¬ 
tion for the PCHQ, it was soon pressed 
into service for an additional function. 
Again due to the depth of the pipelines, 
between the time an exception occurs and 
the time all pipelines have been flushed, 
many operations complete that can gener¬ 
ate additional exceptions. These opera¬ 
tions will not be reissued after exception 
handling, so the exceptions must all be 
recorded and handled en masse. Since this 
exception logging process occurs only after 
the first exception has occurred, and since 
the PCHQ has stopped recording PC 
values at this point, we decided to switch 
the PCHQ from the task of recording PC 
values to the task of recording exception 
records at the time the first exception 
occurs. 


The main memory 
system 

The ideal memory system for a super¬ 
computer would provide large capacity at 
a low price and extremely high bandwidth 
with very low access time. Furthermore, 
the bandwidth and access time would be 
insensitive to the size of the data sets being 
operated on, the manner in which the data 
are placed in memory, and the order in 
which they are referenced. Needless to say, 
such a memory system has never been 
built. Each computer architect must decide 
which of these attributes are essential and 
which can be compromised. 

Data cache anomalies. General-purpose 
computing almost invariably employs 
caches. Assuming locality of reference and 
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Figure 8. Sequentially interleaved memory, (a) The conventional assignment of memory locations to memory modules in a 
sequentially interleaved memory system with four modules. A memory module is busy for four cycles when handling a request. 
Thus, the peak bandwidth is one request per cycle, (b) With a sequential request stream, perfect operation takes place. No 
request ever encounters a busy module, and the peak bandwidth is achieved, (c) For a request stream with a stride of eight, 
every request is directed to the same module. Every request encounters a busy module, the processor must halt three cycles for 
each cycle it advances, and the achieved bandwidth is one request per four cycles. 
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hence a high hit rate, the cache provides 
the desired high bandwidth and, on the 
average, low access time, while the main 
memory provides large capacity at a low 
price. Whereas the assumption of good 
locality is usually true with general- 
purpose work loads, it can be wildly wrong 
in numerically intensive computing. 
Often, numerical applications sweep 
through large arrays such that a particu¬ 
lar element is rereferenced only after all 
other elements have been referenced. 
Except in the case of toy problems, the 
arrays tend to be comparable to the main 
memory in physical size and considerably 
larger than any realistic cache. Conse¬ 
quently, each word is displaced from the 
cache before it is next referenced, result¬ 
ing in a low hit ratio. 

The processor is now working directly 
out of the main memory, which typically 
is underdesigned for this situation, since 
the design assumption was that only a 
small fraction of the references would 
come through to the main memory. Worse 
yet, if the stride with which the processor 
is referencing memory is equal to or 
greater than the cache line size, the cache 
will fetch an entire line for each reference 
that the processor makes, and all but one 


word of the line is wasted. Far from help¬ 
ing the situation, the cache is now com¬ 
pounding the problem by amplifying the 
request rate to an already underdesigned 
main memory. This phenomenon has been 
researched and reported by Abu-Sufah 
and Mahoney. 12 

In the case of a really high-performance 
processor, a further problem makes using 
a data cache difficult. In addition to the 
bandwidth needed for instruction fetch¬ 
ing, it is necessary to perform two or three 
data references per processor cycle to keep 
memory bandwidth in balance with the 
processor’s computational capability. This 
requires the use of either an interleaved 
cache or multiple caches, along with a 
cache coherency mechanism. At extremely 
fast clock rates, both alternatives present 
formidable obstacles. In view of these con¬ 
siderations, we elected not to use a cache 
for data references. We provided a 
32-Kbyte cache for instructions, since 
cache performance for instruction refer¬ 
ences is not qualitatively different for 
numerical programs. 

Sequentially interleaved memory 
architectures. The full operand request 
rate now had to be handled by the main 


memory, and we were back to the problem 
of providing a consistently high bandwidth 
and low access time using main-memory 
technology. In the context of a departmen¬ 
tal supercomputer price objective, this 
meant that using fast, static, ECL RAM 
was precluded, and we had to use the rela¬ 
tively inexpensive but slow MOS DRAM 
technology. The only way to achieve high 
bandwidth with slow memory technology 
is to use multiple memory modules in an 
interleaved fashion. In a normal, sequen¬ 
tially interleaved memory, with an inter¬ 
leave factor of M modules, every M th 
word is in the same memory module (Fig¬ 
ure 8a). In the case of a sequential refer¬ 
ence stream, this ensures high bandwidth, 
since all modules are referenced before the 
same module is referenced again (Figure 
8b). If the degree of interleaving is large 
enough compared with the ratio of the 
memory cycle time to the processor cycle 
time, the memory module will be ready to 
handle another request by the time it is 
referenced again. 

Although interleaved memories can 
provide the bandwidth requirements of 
high-performance processors, they do not 
address the desire for short access times. 
Without the use of a cache, the access time, 
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even under the best of circumstances, can 
be no less than the access time of the mem¬ 
ory technology used in the main memory. 
Since in numerically intensive computa¬ 
tions processor performance is more 
rigidly linked to memory bandwidth than 
to memory access time, supercomputer 
architectures have evolved in such a way 
as to be relatively insensitive to memory 
access time. In vector processors the mem¬ 
ory access time contributes only to the vec¬ 
tor start-up penalty, not to the vector 
execution rate. Likewise, in the dataflow 
and directed-dataflow architectures, a 
longer access time is handled by schedul¬ 
ing the memory access earlier than it is 
needed. 

Parenthetically, this explains why 
general-purpose processors are better 
“MIPS engines” than supercomputers 
running at the same clock speed. In 
general-purpose computing the emphasis 
is less on iterative computations and mem¬ 
ory bandwidth and more on branching, 
procedure calls and returns, and memory 
access time. This makes cache memories 
indispensable. Without its cache memory, 
a high-speed scalar processor would slow 
down to a crawl. 


The stride problem. In well-designed 
supercomputer architectures, the trade-off 
is always in the direction of ensuring con¬ 
sistently high memory bandwidth, even at 
the expense of increased access time. How¬ 
ever, conventional, sequentially inter¬ 
leaved memories cannot guarantee even 
high bandwidth. They break down badly 
if the references have a stride that is a mul¬ 
tiple of the degree of interleaving (Figure 
8c). When this happens, every reference is 
to the very same memory module, and the 
bandwidth is degraded to that of a single 
memory module. The processor’s perfor¬ 
mance drops proportionately. On existing 
supercomputers, the magnitude of this 
penalty is so large 13 that the user is forced 
to contort the algorithm to avoid this 
stride problem. ' \ 

Pseudorandomly interleaved memory 
^architecture. We found Jhis^SituatTon 
unacceptaWe-anddevetoped an interleaved 
memory architecture that is impervious to 
the stride problem. Instead of assigning 
every M th word to the same memory mod¬ 
ule, we assigned the memory locations to 
the memory modules in a carefully 
engineered pseudorandom fashion such 
that every reference sequence likely to 
occur in practice would be as uniformly 



The ideal 
memory system 
for a supercomputer 
would provide large 
capacity, low price, 
high bandwidth, and 
very low access time. 


distributed across the memory modules as 
would a truly random request sequence 
(Figure 9a). To someone familiar with the 
folklore of interleaved memory design, 
this might seem like exactly the wrong 
thing to do. It is a popularly held belief 
that an M -way interleaved memory with a 
random request sequence will only achieve 
a bandwidth proportional to n/AZ modules 
instead of getting the full benefit of th eM 
modules. This is true (Figure 9b) if the 
memory system does not have the facilities 
to queue-up references to busy modules. 14 
With sufficient buffering (Figure 9c), the 
full bandwidth of M modules can be 
achieved. 15 Furthermore, since every 
request sequence, whether sequential, of 
stride M, or totally scrambled, appears 
equally random to the interleaved mem¬ 
ory, this high bandwidth is consistently 
achieved. The only exception is a situation 
in which the same location is repeatedly 
referenced (for instance, a scalar memory 
reference in a loop). Standard, machine- 
independent optimizations in the compiler 
get rid of such situations. Thus, high band¬ 
width is guaranteed regardless of how data 
is placed in memory and how it is 
referenced. 

But, as always, there is no free lunch. 
The price of guaranteeing consistent high 
bandwidth is an increase in access time in 
high-bandwidth situations. When the 
request rate is high (close to the maximum 
bandwidth the memory system is designed 
for), the randomness of the pseudoran- 
domized request sequence will cause 
queues to form every so often on busy 
modules. A request arriving at such a 
queue will experience a delay equal to the 
memory chip access time plus the time 
spent waiting in line. Thus, the access time 
perceived by the processor increases. Also, 
this increase in access time is a stochastic 


quantity, and the overall access time for a 
request now lies within a range of values. 
Whereas the limits on the range can be 
predicted, the exact value (within that 
range) for the access time of a specific 
request cannot. Moreover, this range 
shifts, depending on the request rate of the 
processor. Under light load conditions (as 
when executing scalar code), one can 
expect little queueing delay, but when the 
request rate increases (within innermost 
loops), so will the queueing delay. 

The memory latency register. In and of 

itself, the increased access time is not a 
major problem; the second-order penalty 
due to the increased access time is more 
than compensated for by the first-order 
benefit of guaranteeing high bandwidth. 
(This does, however, cause a further polar¬ 
ization between a well-designed general- 
purpose processor and a well-designed 
supercomputer.) What is of concern is the 
nondeterministic nature of the access time 
in the context of a processor architecture 
in which every operation is rigidly sched¬ 
uled at compile time and in which the 
latency of every operation, including the 
memory operations, must be determinis¬ 
tic. The way other architectures that use 
compile-time scheduling normally handle 
this is to “fake” a deterministic access 
time. 6 If the memory access occurs sooner 
than expected, the data can be buffered 
internally to the memory system and deliv¬ 
ered to the processor at exactly the right 
time. If, on the other hand, the data takes 
longer than expected, the processor is 
“frozen” until the data is available, so that 
in the processor’s “virtual time” the 
request always takes the same amount of 

Yet another delicate trade-off exists 
here. If the compiler consistently underes¬ 
timates the access time, the processor will 
spend a significant fraction of its time in 
a frozen state. If the compiler consistently 
overestimates the access time, the sched¬ 
ules generated at compile time are unneces¬ 
sarily dilated. At either extreme, 
performance is less than optimal. We 
addressed this issue by simulating the 
memory system at various request rates 
and plotting performance against the 
nominal (assumed) memory latency. As 
expected, we found that for each request 
rate the curve peaked at a certain value of 
memory latency. In the vicinity of this 
optimum memory latency, performance 
was not particularly sensitive to the value 
of the memory latency. On the other hand, 
the value of the optimum memory latency 
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Figure 9. Pseudorandomly interleaved memory, (a) The assignment of memory locations to four memory modules in a pseu- 
dorandomly interleaved memory, (b) Even with a stride of eight, eventually the requests are evenly distributed across all four 
memory modules. However, every so often requests will encounter a busy module. If no buffering is provided at the memory 
modules, the processor must halt until the module is no longer busy, (c) Although individual requests might have to wait even 
with buffering, the processor need not. It can continue to issue a request every cycle, yielding full bandwidth. 
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was very sensitive to the request rate. This 
made us nervous about hardwiring the 
nominal memory latency value into the 
compiler and the hardware. 

We solved this problem by incorporat¬ 
ing a memory latency register. The MLR 
is a programmatically writable register that 
always holds the value of the memory 
latency assumed by the compiler when 
scheduling the currently executing code. 
The memory system uses the value in this 
register to decide whether the datum is 
early or late and, consequently, whether 
the datum should be buffered or the 
processor frozen. When executing scalar 
code with little parallelism and a low 
request rate, the MLR is set to the mini¬ 
mum possible memory access time of 17 
numeric processor cycles (each cycle is 40 
nanoseconds). When the program is in an 
innermost loop, the MLR is set to the opti¬ 
mum value of 26 cycles to reflect the 
expected delay due to the higher request 
rate. The MLR allows the compiler to treat 
memory accesses as having a determinis¬ 
tic latency but to use different values for 
the latency in different portions of the 
code so as to always deliver near-optimal 
performance. 

Compiler-scheduled memory modules. 

One of the alternatives we considered, and 
decided against, very early in the design 
process was to place the memory modules 
under the explicit scheduling control of the 
compiler (much like the adder and mul¬ 
tiplier) instead of treating the memory sys¬ 
tem like a black box. Ideally, in such a 
scheme the compiler must know at compile 
time whether or not a set of references are 
to distinct memory modules. It can then 
schedule the initiation of the memory 
requests in such a way that the referenced 
memory module is no longer busy by the 
time the request is made. This would elim¬ 
inate the need for any buffering. Also, 
with knowledge of the (deterministic) 
memory latency that exists in the absence 
of queuing, operations that use the data 
from memory can be scheduled to occur 
no sooner than when the data is available. 
The processor would never need to be fro¬ 
zen, nor would access times need to be 
overestimated. Presumably, the hardware 
would be simpler and less expensive with 
no buffering facilities. Thus, near-optimal 
performance could be achieved if the 
appropriate information were known at 
compile time. 

But commonly occurring program con¬ 
structs can defeat such a strategy. In the 
case of references to X(I ) and X(J), the 


manner in which the variables I and J are 
computed may be such as to preclude the 
compiler’s being able to determine 
whether the modules referenced are dis¬ 
tinct or the same. Another problem lies 
with subscripted-subscript references to 
arrays, such as X(JA (/)), where the index 
into one array, X (), is determined by read¬ 
ing the contents of another array, JA (/). 
Since the contents of JA () are determined 
at runtime, the compiler is once again un¬ 
able to predict which module will be refer¬ 
enced. In such circumstances the compiler 
must either assume the worst and serialize 
all such references or assume that no con¬ 
flict exists and count on the presence of 
some hardware mechanism that will freeze 
the processor if a request is submitted to 
a busy module. With the latter approach, 
the VMlaw becomes applicable. In either 
case the program experiences a sizable 
drop in performance. 

As we see it, the most serious drawback 
of compile-time scheduling of memory 
modules is that it does nothing to address 
the stride problem. With a bad stride, 
whether compile-time memory disambig¬ 
uation works or not, the memory band¬ 
width collapses. Memory disambiguation 
merely confirms the bad news at compile 
time. Using pseudorandom interleaving to 


solve the stride problem would make the 
task of compile-time disambiguation next 
to impossible. So eventually the trade-off 
was one of simpler hardware, more com¬ 
plex software, and a reduced average 
access time versus a guaranteed, consis¬ 
tently high bandwidth. In view of our cen¬ 
tral objective of providing a product with 
minimal difficulty of use, we chose the 
latter. 


Reflections 

While developing this product, we 
became aware of certain broad truths, and 
we have tried to convey them in this arti¬ 
cle. The most important of these is that the 
behavior of general-purpose and numeri¬ 
cally intensive work loads can be drasti¬ 
cally different. In nonnumeric programs 
the emphasis is on branching and proce¬ 
dure calls; in numeric programs it is on 
loops. General-purpose jobs tend to access 
their data with a high degree of locality. 
This is not always so with numerically 
intensive jobs. 

Consequently, the design decisions and 
trade-offs steadily push the well-designed 
scalar processor and the well-designed 
numeric processor apart. In a scalar 
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processor the emphasis is on short pipeline 
latencies rather than on extensive parallel¬ 
ism. In a numeric processor the emphasis 
is on multiple, parallel pipelines even at the 
expense of very deep pipelines and, hence, 
reduced scalar performance. Whereas the 
use of caches for data is virtually manda¬ 
tory for good performance in a scalar 
processor, it is far less beneficial, and 
sometimes even detrimental, to the perfor¬ 
mance of a numeric processor. A numeric 
processor is more sensitive to memory 
bandwidth and less so to access time. The 
opposite is true for a scalar processor. 
Thus it remains as difficult now as it has 
been in the past to design a single machine 
that is best for both numeric and nonnu¬ 
meric work loads. 

Much has been said over the past few 
years about the relative merits of RISC and 
CISC approaches to hardware design. We 
feel that the same issue could well be raised 
regarding software, specifically compiler 
software. With the headlong rush to move 
complexity out of hardware and into soft¬ 
ware, compilers are beginning to groan 
under the burden of newly acquired 
responsibilities. It is possible to go too far 
and to end up increasing the total complex¬ 
ity of the hardware-software system. The 
designers’ responsibility is to minimize 
overall complexity, not just that of the 
hardware. In the Cydra 5 we decided not 
to transfer complexity from hardware to 
software in some areas such as the context 
register matrix, conditional scheduling 
control, and hardware-scheduled memory 
modules. To paraphrase Einstein, “Hard¬ 
ware should be as simple as possible, and 
no simpler.” 

Designing and developing a product of 
this performance level and with these capa¬ 
bilities necessitated a break with architec¬ 
tures of the past so that we could 
incorporate a more powerful model of 
computation. This meant that we often 
had to fly by the seat of our pants, there 
being little experience or data on which to 
base our decisions. Fortunately, we have 
not yet discovered any major blunders, 
although it is quite possible that the 
machine has been overdesigned in various 
places because of our tendency to err on 
the safe side. These areas of overdesign 
will reveal themselves slowly as we build up 
our experience in the use of this new archi¬ 
tecture. 

T oday, a number of Cydra 5 sys¬ 
tems are in use at customer sites. 
The performance of these systems 


has met our expectations. On widely 
quoted industry-standard benchmarks 
such as Unpack 16 and the Livermore For¬ 
tran Kernels, 17 the Cydra 5 delivers 15.4 
Mflops and 5.8 Mflops, respectively. This 
is the highest performance of any 
minisupercomputer (even those whose 
peak performance is twice that of the 
Cydra 5) and about one-third the perfor¬ 
mance of a Cray X-MP supercomputer, 
which has nine times the Cydra 5’s peak 
performance. On the 24 Livermore For¬ 
tran Kernels taken as a group, the Cydra 5 
can achieve 23 percent of its peak perfor¬ 
mance as opposed to 15 percent and 8 per¬ 
cent for VLIW and vector processors, 
respectively. On Linpack, which is con¬ 
siderably more vectorizable, the Cydra 5 
achieves 60 percent of its peak perfor¬ 
mance. The VLIW and vector processors 
achieve only 40 percent and 20 percent, 
respectively. 

On other, less vectorizable, bench¬ 
marks, such as ITPack 18 (an iterative 
sparse-matrix solver), the Cydra 5 
achieves half the performance of the Cray 
X-MP. We have even encountered a cou¬ 
ple of extremely nonvectorizable applica¬ 
tions in which the Cydra 5 has actually 
achieved parity with the Cray X-MP. In 
general, across a spectrum of applications. 
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the Cydra 5 can achieve between one- 
fourth and two-thirds the performance of 
a Cray X-MP, depending on the extent to 
which the application is vectorizable. 
However, there is still room for improve¬ 
ment, since the compiler has not yet 
peaked in its ability to wring performance 
out of code. □ 
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Tom Jones 

Convex Computer Corporation 


T he Convex C220 and C240 super¬ 
computers are a family of 64-bit 
multiprocessors, tightly coupled 
through a shared main memory. Each 
processor contains an integrated vector 
processor. All processor features, includ¬ 
ing the vector processor, are controlled by 
a microcoded instruction set. The system 
is implemented in 100K emitter-coupled 
logic, with a cycle time of 40 nanoseconds. 

Two systems are available. The C220 
contains two processors, an I/O system, 
and memory in a 31-inch-wide cabinet. 
The C240 contains four processors, a 
larger I/O system, and memory in a 
57-inch-wide cabinet. This article describes 
the design process for this computer family 
and tries to illuminate the methods and 
rationale behind project-related decisions. 

The C2 design team cannot claim to 
have made flawless decisions. Indeed, on 
several occasions we narrowly avoided dis¬ 
aster. I want to show some of the real-life 
problems we faced and relate our 
approach to resolving them. This confron¬ 
tation with crisis is what makes product 
design so challenging and rewarding. 

C1-C2 comparison 

The Cl system was designed in early 
1983 using transistor-transistor logic 
(TTL) and complementary metal-oxide 
semiconductor (CMOS) technologies. The 
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Big proj’ects entail big 
risks. Those who 
design and develop 
supercomputers must 
be willing to make 
tough choices, battle 
frequent crises, and 
improvise endlessly. 


bulk of the machine was FAST medium- 
scale-integration (MSI) and small-scale- 
integration (SSI) logic, with the vector 
functional units built out of 8,000-gate 
CMOS gate arrays. The original Cl, later 
dubbed the Cl-XL, had no scalar floating¬ 
point hardware; instead it sent the oper¬ 
ands to the vector processor. 

In 1984 floating-point add-and-multiply 
functional units were designed in 
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20,000-gate CMOS gate arrays, and the Cl 
was upgraded to the Cl-XP. That 
machine, with minor changes, became the 
C120 upon announcement of the C2. Fig¬ 
ure 1 shows a block diagram of the Cl. 

The Cl embodied our belief that we 
could use a relatively low cost memory sys¬ 
tem. The memory cards are four-way 
interleaved, and there is a single 
80-megabyte-per-second memory path. 
We accelerated the random access perfor¬ 
mance of the memory with a physically 
addressed 64-kilobyte “P-cache.” P-cache 
data is loaded in blocks of 32 bytes, and 
CPU accesses are held while cache misses 
are serviced. Most vector accesses bypass 
the cache, but large-stride accesses are 
encached. 

The single memory port in the Cl is 
demand multiplexed between the CPU and 
the I/O subsystem. The I/O system trans¬ 
fers data to and from memory via an 
80-Mbyte/s block multiplexer path called 
the P-bus. The CPU does not program the 
controllers directly but sends messages in 
memory to a number of channel control 
units (CCUs) on the P-bus. The P-bus is 
also used to attach a 68000-based service 
processor (SPU), which can access, via 
scan, about 2,200 bits of processor 
registers. The SPU, which runs Unix, has 
a 20-Mbyte hard disk and a floppy tape 
drive as peripherals. 

The Cl CPU executes a single instruc¬ 
tion stream, accelerated into an instruction 
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Figure 1. The Convex C120 system. 



cache. The main locus of control is the 
address and scalar processor, which is 
microprogrammed using writable control 
store. 

The vector processor contains three dis¬ 
tinct microprogrammed controllers dis¬ 
patched to execute vector instructions. 
Logical addresses are 30 bits, with the most 
significant bits signifying protection seg¬ 
ments. Logical addresses are translated to 
physical addresses using an address trans¬ 
lation cache. 

A 1-Kbyte data cache in the CPU is 
accessed logically while the address is being 
translated. This cache is write-through and 
is tagged on a word basis. 

By contrast the C2, designed in 1986, 
uses 100K emitter-coupled logic (ECL). 
Over 150 gate arrays of 14 different types 
were used, in addition to about 3,000 
packages of MSI and SSI logic. Although 
we implemented the vector processor data 
paths in 20,000-gate CMOS, the bulk of 
the gate arrays were 3,000-, 7,000-, and 
10,000-gate ECL. Figures 2 and 3 show the 
structure of the C2 CPU and system. 

The C2 uses a more expensive and much 
higher performance memory system than 
the Cl. The C2 memory is organized as 
pairs of 39-bit memories (32 data bits with 
seven bits of error-checking-and- 
correction code) rather than as a single 
64-bit memory. There are five discrete 
paths into the memory system, and each 
memory board has eight independent 
banks. 


Figure 2. The Convex C240 processor. 


Unlike the Cl, the C2’s crossbar feature 
allows CPU and I/O functions to access 
memory simultaneously. The crossbar is 


built in gate arrays on each memory board. 
Besides providing the crossbar function, 
these arrays buffer the backplane and con- 
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Figure 3. The Convex C210-C240 system architecture. 


tain staging FIFOs to and from memory 
users. Each port operates at 25 MHz, or 
200 Mbytes/s. There is no analog to the 
P-cache. 

The C2 I/O subsystem has its own mem¬ 
ory port, which is used by a peripheral 
interface adapter. The PIA supports a pair 
of P-buses. This allows Cl CCUs, as well 
as new CCUs developed for the C2, to be 
attached. This port is used by the service 
processor as well as by the PIA. 

The service processor, which has scan 
access to approximately 25,000 register 
bits in the C2, has a 180-Mbyte disk and a 
streaming cartridge tape drive as 
peripherals. 

As in the Cl, the C2 CPU interprets a 
single instruction stream and dispatches 
appropriate microcontrollers in the 
address and scalar processor or in the vec¬ 
tor processor. Hardware support in the 
address and scalar processor is very direct. 
Almost all instructions execute in a single 
cycle, except for complex instructions such 
as system calls. 

In addition to the instruction cache and 
address translation cache, each CPU con¬ 
tains a 4-Kbyte data cache that is logically 


addressed and accessed while address 
translation is in progress. If a hit occurs in 
the data cache, the memory reference will 
be killed before the memory can be started. 
Since each processor contains its own 
cache, cache coherence must be enforced 
by a series of hardware-controlled invali¬ 
dation tag stores. 

In addition to the shared memory path, 
the C2 processors share a communication 
register file, which has some interesting 
properties. It is organized as eight frames 
of 128 64-bit-wide registers. Registers have 
intrinsic semaphores, allowing implemen¬ 
tation of primitive send/receive operators. 
Processes are mounted to frames, and 
processors dynamically allocate them¬ 
selves to frames. This facilitates our imple¬ 
mentation of dynamic processor 
scheduling, called asynchronous self¬ 
allocating processors, or ASAP. 

Product definition 

Convex began regular debates on the 
definition of the C2 before the Cl proto¬ 
type was even in the lab. In retrospect, our 


sense of timing was amusing. These 
debates were merely philosophical, since 
we had no resources to commit to the proj¬ 
ect. Indeed, every scrap of human or mate¬ 
rial capital at our disposal was wrapped up 
in Cl development activity. 

This situation changed in mid-1985. The 
first production Cl had shipped in March, 
the early-life sustaining activity was wind¬ 
ing down, and the moment of decision 
confronted us. Not only were we finally 
able to start another project, we would 
have to do so or idle the engineering staff. 

Years of debate had hardened the vari¬ 
ous positions while doing little to resolve 
the differences. Almost every engineer 
wanted to build a heavily integrated 
CMOS implementation. CMOS technol¬ 
ogy had been developing rapidly, and 
some of our competitors were making 
good use of it. We felt we could build a 
Cl-class machine at much lower cost. In 
a sense, we were captivated by the techni¬ 
cal possibilities. 

Balanced against this was the vision of 
Bob Paluck, company president. He had 
been spending most of his time with cus¬ 
tomers and potential customers, not in the 
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lab. He believed the real opportunity was 
at the high end, and he wanted us to build 
the fastest machine possible. 

This highlights one of the prime advan¬ 
tages existing companies have in defining 
products. They have customers who 
bought their products and noncustomers 
who looked but didn’t buy. This data is 
vastly superior to market surveys, which 
might be thought to yield the same results. 
There is a moment of truth—when it’s 
time to spend money—that reveals a cus¬ 
tomer’s real needs and biases. Even then 
it takes a lot of interpretation to make deci¬ 
sions about the next product, but at least 
a company will have a firm starting point. 

Once we decided to increase perfor¬ 
mance, other issues still needed to be 
resolved. Parallel processing had become 
extremely important to computer buyers. 
Sometimes this was for performance rea¬ 
sons, but just as often it was a matter of 
having the latest technology. An inte¬ 
grated vector machine like the Cl might 
well be the fastest machine on the market 
for a given application, but it lacked the 
cachet of parallel processing. 

We had consciously decided against par¬ 
allel processing while designing the Cl. We 
felt we would be able to trim months off 
the time to market by staying with a 
uniprocessor design. The hardware was 
simpler to design, and the Unix operating 
system had been developed on a uniproces¬ 
sor. We believed it would port and tune 
more easily. Finally, we felt comfortable 
with vectorizing compiler technology in a 
uniprocessor environment and thought we 
could develop it more quickly. 

We were mostly right on all points. We 
shipped our first machine about nine 
months earlier than our competitors with 
parallel processors, who had started about 
the same time. That lead turned out to be 
vital as the industry developed. 

As time went on, however, these com¬ 
petitors beat the Cl on benchmarks more 
than once. There truly were programs that 
could be parallelized but not vectorized, 
although that was not generally the case. 
More often, we lost sales because the cus¬ 
tomer simply wanted a parallel machine. 
When spending that much money, espe¬ 
cially with a start-up vendor, a customer 
wants to be sure of getting the latest and 
greatest technology. In any case, we deter¬ 
mined to fix both the technical and mar¬ 
keting problems. C2 would be a parallel 
machine of one flavor or another. 

Two popular paradigms existed for par¬ 
allel processing: shared memory and local 
memory. We chose shared memory 


because we believed we could build a com¬ 
piler to target it while compiling existing 
programs. We believed that if you cannot 
inherit the existing software base, you are 
unlikely to succeed commercially. New 
applications occur at a finite rate; only by 
inheriting old ones can you grow fast 
enough to stay ahead of the pack. 

For the same reasons, we believe in 
coupling a few fast processors rather than 
many slower ones. Programs, especially 
preexisting ones, have annoying amounts 
of scalar code, which neither vector nor 
parallel architectures have much effect on. 
Also, there are limits to the amount of log¬ 
ical parallelism in the source code. Many 
programs will perform asymptotically 
after just a few processors are in play. The 
bottom line is that a few fast processors 
sharing memory are easier to program 
than any other configuration, and ulti¬ 
mately the most easily programmed archi¬ 
tecture will prevail. 

Beyond parallelism, we wanted to 
extend C2 performance as much as possi¬ 
ble. Several major extensions were 
included. We added intrinsic functions 
such as sine and square root to the scalar 
instruction set, as well as vector convert 
instructions. We nearly doubled the vec¬ 
tor instruction set to allow element-by- 
element conditional execution of vector 
instructions. 

Everyone had opinions about what was 
right and wrong with the Cl, and we 
decided to sort fact from fiction early in 
the C2 program. The project’s first Cl was 
modified to generate data for a PC-based 
performance monitor. Over several 
months we ran many programs, some 
small and some enormous, and analyzed 
the data. This allowed us to be objective 
about the Cl and led to a performance 
increase of about 20 percent beyond what 
clock scaling would predict. One side ben¬ 
efit of this approach was its efficiency. 
Philosophical arguments can waste an 
amazing amount of time when the facts are 
missing. 

The cache system required a major over¬ 
haul. Performance monitoring had shown 
that the two-level cache system in the Cl 
exhibited some pathological thrashing 
problems. In particular, the large write¬ 
back cache in the memory system per¬ 
formed poorly on some vector programs. 
Scalar code segments would accelerate 
data into the cache, and vector code would 
subsequently touch the same data. Pipelin¬ 
ing broke down severely in these cases. 

The C2 solution was to use a single- 
level, write-through cache in each proces¬ 


sor, with a hardware invalidation system 
between processors. Write-through is not 
a very popular system these days because 
of memory bandwidth requirements. 
However, vector processors already 
require extreme memory bandwidth, so 
write-through is easy. 

The cache size turned out to be a trade¬ 
off between latency and hit rate. We could 
have improved the hit rate at a cost of dou¬ 
bling hit latency from one clock to two. 
We went with latency because our intent 
with large programs, which can benefit 
from the larger cache, was to vectorize. 

In addition, all vector references (32- 
and 64-bit of any stride) reference main 
memory directly, bypassing the cache. 
With the memory system structured as two 
independent 32-bit paths, two 32-bit vec¬ 
tor accesses can be executed simul¬ 
taneously. 

Even with these enhancements, com¬ 
patibility with our existing C1 product was 
a must. Along with our customers, we 
were investing heavily in the development 
of software packages tuned for our archi¬ 
tecture. Throwing that away would have 
been foolish. 

Not so obvious, perhaps, is that binary 
compatibility was also a requirement. The 
industry likes to think that coding in a 
portable, high-level language has taken all 
the sting out of code porting. True, it has 
become relatively painless to move many 
scalar codes. However, many of the 
interesting Convex applications are heav¬ 
ily tuned against our architecture. Some of 
the large third-party applications— 
MSC/Nastran and Ansys, for example— 
take months to validate, even if they port 
without difficulty. Convex simply did not 
have sufficient personnel to battle our way 
back to where we had been with the Cl. 
We had to make it trivial to validate Cl 
packages on the C2, and strict binary com¬ 
patibility does as much as possible to that 
end. 

We knew that most system users are 
more interested in throughput than in per¬ 
formance on a single program. This may 
seem illogical, since computers are most 
often bought on the basis of their bench¬ 
marks for a single program or a set of pro¬ 
grams. However, once the machine is in 
the hands of users, sustainable throughput 
and robustness become paramount. 

This implied that we needed to develop 
a system competent in both the benchmark 
and the time-share environments. This 
may seem trivial, but it isn’t. The impact 
particularly lands on the mechanisms used 
to achieve parallelism, and this led us to a 
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significant innovation, the ASAP schedul¬ 
ing mechanism previously described. 

Finally, we decided to save as much of 
the existing Cl system as possible so that 
we wouldn’t have to redesign any more 
than necessary. Frankly, we were strapped 
for resources and needed to conserve any¬ 
where we could. 

We chose an I/O system design that 
would let us use the Cl I/O system until it 
could be replaced by a higher performance 
system. This caused some debate because 
the large increase in CPU performance 
would seem to mitigate a proportional 
increase in I/O performance. But the 
robust and proven Cl I/O system had 
more performance than the Cl could use. 
We expected enough problems with the 
subsystems that absolutely had to be 
redesigned, and we didn’t need any 
unnecessary exposure. 

Although not originally planned, we 
even used the Cl industrial design. When 
we picked up the Cl I/O system, the easi¬ 
est thing to do was to use the Cl peripheral 
cabinets. So instead of doing the whole 
thing over, we just designed the C2 cabi¬ 
nets to match. Besides saving money, this 
had two important effects. First, we were 
able to upgrade Cls in the field by unbolt¬ 
ing the Cl processor cabinet and bolting 
up a new C2 cabinet. Second, we avoided 
the debate about industrial styling, which 
had been nearly endless during the C1 pro¬ 
gram. Only a few people in the company 
know enough to critique an architecture, 
but everyone feels competent to judge 
matters of style. 


Technology selection 

One of our objectives was to make arbi¬ 
trary programs run three times faster on 
the C2 than on the Cl. The only certain 
way we knew of for doing this was by 
cranking the clock cycle down without 
increasing the pipeline depth. 

The Cl had a clock cycle of 100 nanose¬ 
conds, allowing us to use FAST and 
CMOS technology. We could have gone to 
a faster clock cycle in the same technology 
by using more pipelining, but it wasn’t 
clear that this would give us the desired 
performance level, particularly on a broad 
range of applications. We felt more con¬ 
fident using faster technology to scale 
something resembling a Cl processor 
architecture. Our initial target for the 
C2—33 nanoseconds—made emitter- 
coupled logic the prime contender. 




One of the big risks 
we took was using 
programmable 
array logic. 


We knew some competitors were aiming 
at the same cycle times, and faster, with 
CMOS, but the approach didn’t look via¬ 
ble to us. Even though on-chip gate speeds 
can be very fast, off-chip drivers tend to be 
slow. Our experience was that pipelined 
structures such as the vector processor 
could exploit CMOS because many levels 
of pipelining could exist on a single chip. 
The trouble started in more random struc¬ 
tures like the scalar processor and in 
transmission-line environments like the 
backplane. We ended up with a hybrid 
approach. 

We used CMOS anywhere we could get 
away with it and ECL wherever needed. 
This eventually meant that the vector 
processor data paths were built from 
20,000-gate CMOS gate arrays, while 
everything else was ECL. 

Choosing ECL moved us along to the 
next decision. The two real contenders in 
the ECL world, 10KH and 100K, each 
claimed superiority. Because 10KH was 
newer and gaining popularity, we thought 
higher volumes would make it cheaper. 
Furthermore, it used a smaller, “slim¬ 
line” package. 

On the other hand, 100K had been 
around for years. It offered both power 
supply and temperature compensation on 
voltage thresholds, which had a lot of 
appeal in a big system. I’m not sure these 
features would matter in a small system, 
such as a workstation, but they were cer¬ 
tainly attractive in a system with many 
large boards. There is a substantial tem¬ 
perature differential across the board, as 
well as a voltage differential from front to 
back. 

Finally, the 100K power pins were in the 
middle of the package, which reduced their 
lead inductance, and we expected this to 
improve noise margins. All things consid¬ 
ered, we chose 100K. 

Our original inclination was to mount 
gull-wing, flat packages on double-sided, 


surface-mount PC boards. We were afraid 
the faster gate speeds of ECL would be 
diluted by the etch delays, and we wanted 
to cram the ICs in as tightly as possible. 
But a host of practical considerations 
intervened. Convex had a well-established 
multiwire board technology that we were 
comfortable with. Multiwire has big 
advantages in terms of low tooling cost, 
fast prototyping, and quick production 
start-up. The dual in-line package, 
through-hole approach in multiwire tech¬ 
nology was also well developed and quite 
reliable. In the end we felt the speed advan¬ 
tage of denser packaging wasn’t worth the 
risk and cost of development. 

One of the big risks we took was using 
programmable array logic (PAL). 
Although widely available in the TTL 
world, it was available only on data sheets 
in ECL 100K when we were doing the 
design. 

Three vendors were working on this 
part. To date, only one has delivered parts 
to us. One vendor canceled the program 
and the other has slipped badly. We wor¬ 
ried a lot about the part because if it had 
flopped, we would have had to redesign 
the product, severely compromising our 
cost and performance goals. 

We needed many hundreds of these 
arrays per machine, so we were really 
dependent on vendors. ECL 10K PAL 
devices were available, and we had sam¬ 
pled prototype 100K parts that worked 
fairly well. We felt pretty certain that one 
of the three vendors would come through 
eventually. The real question was whether 
or not they would make it by the time we 
were ready to power-on the system. It 
turned out to be very close. 

The gate-array technology we used was 
also available only on data sheets. Quite a 
few vendors claimed they would be able to 
deliver the technology we needed when we 
needed it. The problem was deciding 
which one, if any, really could. 

In the end we stayed with the vendor of 
the Cl gate arrays. Their proposed tech¬ 
nology was equivalent to everyone else’s, 
and they had proved dependable. Further¬ 
more, when things had gone wrong, they 
had taken pains to support us. When 
entering unexplored territory, it’s best to 
go with people you know and trust. 

A widespread concern with ECL is the 
power dissipation. Getting rid of power 
wasn’t so difficult; getting it into the chips 
turned out to be the tough part. 

The problem started with the back¬ 
plane, something logic designers take for 
granted. Although large, the Cl backplane 


40 


COMPUTER 










had never really been a problem because 
the thickness was tolerable. Since the tech¬ 
nology wasn’t all that complex, we had 
multiple Cl backplane suppliers from the 
start. The C2 backplane, though, was 
another matter. 

We expected—and encountered— 
routing difficulties because the wiring den¬ 
sity was higher than on the Cl. The real 
problem, though, came from the power 
and ground distribution. It took a lot of 
copper to hold the voltage differentials 
down on a fully loaded system. The back¬ 
plane got thick, over 0.3 inch, giving the 
backplane fabricators fits. The wiring den¬ 
sity required small vias, and the thickness 
forced us into aspect ratios on the vias that 
made it difficult to make the boards relia¬ 
bly. Although this process is pretty well in 
hand today, it was touch and go for a long 
time. It was grimly amusing to find our¬ 
selves in such peril over something we had 
taken for granted. 

We also used a large power distribution 
plane to get the power from the supplies to 
the backplane, and this too proved very 
difficult to manufacture. In both cases, 
however, we were able to execute new 
designs that overcame these problems, 
once they were well understood. The real 
difficulty for us and for the vendors had 
been a failure to anticipate all the problems 
we would encounter in pushing at the 
boundaries of current commercial technol¬ 
ogy. This emphasizes again the need to 
select vendors at least partially on the basis 
of their willingness and ability to work 
with you when things go awry. 

The backplane was only the most down¬ 
stream of the power problems. The C2 
uses 360A DC power supplies, and those 
were just a spec sheet when we included 
them in the design. Fortunately, we 
secured two vendors for this item. Our pri¬ 
mary supply fell through because of ther¬ 
mal problems; the secondary supply came 
through late, but fully operational. A sec¬ 
ond source can make life much easier, 
which is why purchasing people are so ada¬ 
mant about it. However, if you are really 
pushing the state of the art, it is only pos¬ 
sible occasionally. 

Connectors, another item logic 
designers take for granted, also caused a 
lot of worry. We had used 96-pin DIN con¬ 
nectors on the C1. They were cheap, relia¬ 
ble, and widely available. Our only 
problem was sorting out the quality ven¬ 
dors from the also-rans. 

The C2 needed almost twice as many 
pins as the C1. We also needed to pass a lot 
more current, so we selected a high-density 



We reached decisions 
democratically, 
but a dictatorship 
waited in the wings. 


connector with special power tabs on the 
sides of the connector body. But once 
again the part existed only on paper. 

Luckily there were two vendors, but 
their parts were not interchangeable. And 
we encountered an additional twist. After 
deciding to go with the vendor who could 
deliver parts, we learned that the losing 
vendor held a patent that our vendor was 
infringing on. Happily, they arrived at a 
licensing agreement, but not before things 
got a bit nerve wracking. 

In retrospect, I’d say we exercised good 
engineering judgment and had outstand¬ 
ing luck. Many things could have shut us 
down, but we always dodged the bullet. 
Finding vendors who will work with you, 
on your schedule, when things are going 
badly is vital. We give vendors the same 
scrutiny we give potential employees. If we 
wouldn’t hire them directly, why should 
we let them hold our destiny under 
independent management? 

One of the best ways to find good ven¬ 
dors is to look at those servicing existing 
products, assuming you already have simi¬ 
lar existing products. Starting up or mak¬ 
ing big technology leaps is much more 
dangerous. 


Staffing and 
organization 

It takes good ideas to make good 
products, but the right idea by no means 
ensures success. Execution is necessary, 
and this depends on your people. Thus, 
staffing and organizing the project was a 
major concern from the beginning. 

Organization within Convex was a deli¬ 
cate issue. One idea was to run C2 devel¬ 
opment out of the existing engineering 
organization, ensuring ready access to the 
skills and experience of the Cl staff. The 
other, and ultimately prevailing, philoso¬ 
phy recognized that engineering was domi¬ 


nated by Cl support, sales, and 
enhancements and that only a separate 
organization would be focused enough to 
produce the desired results. 

As an experiment, we tried to run it for 
a while out of the engineering group, but 
it really didn’t work. We were too easily 
distracted by the daily C1 crises to concen¬ 
trate on the new product. 

Deciding to create an autonomous unit, 
we moved into an unoccupied area in the 
back of the Convex facility, equipped to 
be as self-sustaining as possible. We had 
our own entrance, our own computers, 
even our own refrigerator and microwave 
oven. It was a company within a company, 
devoted entirely to development of the C2. 
On the down side, we had essentially no 
structure to support the finer points of 
career development, such as a visible 
future. 

We kept to ourselves, as you might 
expect, which facilitated secrecy. We pre¬ 
ferred that project plans not appear in 
general notes on the Unix network, so we 
restricted access to all C2 information. We 
even walled ourselves off from the rest of 
the building, leaving only one way in and 

All this may have given the C2 group a 
feeling of unity and purpose, but it created 
hostility within the rest of the company. I 
even heard that another organization’s 
staff had applauded upon hearing that we 
had slipped. True or not, the story was 
hardly surprising. Our closely focused 
elitist approach deeply offended many of 
our co workers. 

We reached decisions democratically, 
but a dictatorship waited in the wings. 
There was no formal channel for conflict 
resolution; the designers involved hashed 
out most decisions themselves. If they 
couldn’t agree, an informal group of sen¬ 
ior designers usually intervened. If this 
group deadlocked, one of the managers 
would decide. The advantages of this 
approach were speed and effectiveness. 
We could all hear the clock ticking, so we 
didn’t spend a lot of time fretting about 
optimal solutions. 

Although we had taken a core of 
designers from the Cl group, we weren’t 
at full strength, and acquiring the neces¬ 
sary staff was no small task. Richardson, 
Texas, is not the center of the computer 
universe—at least not yet. 

Nevertheless, some local defense con¬ 
tractors build complex logic systems, and 
from them we hired some excellent (and 
restless) engineers. Being nicely in phase 
with the university hiring cycle was benefi- 
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cial, too. In addition, we hired a few 
experienced computer designers from 
other geographical areas. 

Surprisingly, CPU designers were not 
the hardest positions to staff. Finding 
good I/O designers seemed all but impos¬ 
sible, although we finally succeeded. Diag¬ 
nostic engineers constitute another tough 
category, as do technical writers. I think 
we, as an industry, fail to adequately edu¬ 
cate and motivate engineers for these 
specialties, an oversight that undermines 
the potential quality of our products. 

Nine months after the project started, 
we were fully staffed. At times it seemed 
that all we did was recruit, but all the while 
the project was moving steadily ahead. 
The architecture and support structures 
were defined well enough for people to 
come in and start producing immediately. 
Though we could have filled positions 
sooner by lowering our standards, we were 
never tempted to. Ultimately, you win or 
lose because of your people, and you have 
to keep searching for the winners. 

The C2 has been a smashing success, 
and the people responsible are much in 
demand in a fast-growing company like 
Convex. We certainly didn’t lay people off 
as they finished. They were either assigned 
to new projects or reassigned to hot spots 
on the C2 project. As the product was 
introduced into manufacturing, the C2 
project organization dissolved. Happily, 
resentment over its separateness also dis¬ 
solved. 

We didn’t do everything right, but I 
think our fundamental strategy was 
sound. Putting a large chunk of corporate 
resources into an independent project 
really rankles the departmental organiza¬ 
tions, and that cost must be considered. 
But it facilitates a level of focus and a 
schedule that can compete with start-ups. 
It also energizes the project, instills com¬ 
mitment, and makes the work enjoyable. 

I feel fortunate to have been involved with 
the project. 

Tools 

We felt certain we could not design the 
C2 with the Cl tool set. Although we had 
automated schematic capture tools during 
the Cl project, our computing facility was 
a single VAX 11/780. The VAX ran Unix 
during the day, when it served as the soft¬ 
ware development and general time¬ 
sharing machine. At 8 p.m. VMS was 
loaded and the VAX would spend the 
night grinding away at logic simulation 


and timing verification on the gate arrays. 

This technique allowed the Cl gate 
arrays to work the first time. The boards, 
by comparison, had been designed and 
wire-wrapped in five months but had to be 
debugged for the next year. 

The board designers wanted to duplicate 
the Cl application-specific integrated cir¬ 
cuit (ASIC) success on the C2 boards. To 
that end we decided to simulate the entire 
design, first at the behavioral level, then at 
the gate level. Figure 4 shows the topology 
of our simulation approach. Because we 
expected to burn most of our cycles doing 
behavioral simulation, we selected the 
fastest behavioral simulator available. 
Unfortunately, it had no gate-level simu¬ 
lation, so we had to build our own gate- 
level models. 

Though not elegant, this solution 
worked. At that time no vendor had a 
complete tool set that would satisfy our 
requirements, so we glued a bit of this and 


a bit of that together with a lot of C code 
to build the CAD system we wanted. I 
don’t believe such a tool set is available 
from vendors even now. 

Software simulations were also 
upgraded in the move from Cl to C2. Cl 
development had used an instruction-set 
architecture simulator to develop and test 
the product’s software. Since the simula¬ 
tor had been rather slow, C2 developers 
made speeding it up their first priority. 
This tool was instrumental in the overall 
development cycle because it enabled us to 
debug hardware with fully functional soft¬ 
ware. Because we could first run the oper¬ 
ating system on this simulator, it came up 
on actual hardware in a matter of days. 

Tool performance will become increas¬ 
ingly important. Although computer 
designers like to think that architecture 
and design decide the outcome, I believe 
our business is fundamentally driven by 
semiconductor technology. Whoever 


m 



Figure 4. The Convex C2 simulation topology. 
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translates new semiconductor technology 
into new products quicker and more effec¬ 
tively has a tremendous edge. Superior 
design talent is still needed, but having the 
design technology to back it up is now a 
necessity rather than a convenience. 

Obviously we needed to focus on tech¬ 
nology, but the issue wasn’t that simple. 
For a resource-constrained company, 
every CAD designer means fewer logic 
designers. From a resource point of view, 
it was a zero-sum game, and we wanted the 
maximum bang from a limited number of 
bucks. This demonstrates project organi¬ 
zation at work, because the project man¬ 
ager is forced to apportion money among 
the various disciplines. 


Execution 

Naturally you plan for success, but the 
best of plans can go awry when the proj¬ 


ect confronts harsh realities. Success at 
that juncture may well depend on an abil¬ 
ity to improvise. When everything was 
going wrong was when I most appreciated 
our project orientation. Engineers did all 
sorts of things that weren’t in their job 
descriptions to somehow solve each crisis 
and keep the project moving. 

By May 1986 the key architectural deci¬ 
sions had been made, the critical mass of 
engineering staff had been established, 
and the tools were working pretty well. I 
use that qualifier because active use was 
exposing all the flaws. Some of the logic 
and diagnostic designers, along with the 
CAD engineers, were improvising furi¬ 
ously in the CAD area. It all came together 
in the fall, though, and by the end of the 
year a full behavioral simulation was in 
final debug. 

Even as we were finishing the behavioral 
simulation, we were also doing gate-level 
design and preliminary timing. One thing 


had become very clear: 33 nanoseconds 
was a pipe dream. With our margin 
requirements, 40 nanoseconds was much 
more reasonable. Actually, timing was 
verified at 34 nanoseconds, manufactur¬ 
ing normally tests at 36 nanoseconds, and 
the machine operates in the field at 40 
nanoseconds. 

We fixed these timing parameters early 
enough in the gate design stage for all 
boards and gate arrays to be designed to 
them, and the numbers turned out to be 
pretty good. They weren’t easy to make, 
but we didn’t thrash trying to achieve 
them, so they must have been about right. 

Then came the first great partitioning. 
We had been running behavioral simula¬ 
tions, splicing in gate-level designs to prove 
them. Finally we had to put all the gates on 
boards, and of course there weren’t 
enough square inches or connector pins to 
support them. So, we went back to the 
design shop. 

Several attempts later, the design fit and 
worked; then the next problem emerged. 
The C240 machine had to be postponed at 
this stage. Fitting the cache coherency logic 
for four heads would have required two 
additional gate arrays, which would have 
made us late on our schedule. So we 
directed the mechanical design toward a 
two-headed machine. We also decided at 
this point that the first machines to ship 
would be single headed, running the C1 ’s 
software. 

This decision was extremely important 
because it meant the first thing out the 
door would be almost entirely a hardware 
project, with minimal software dependen¬ 
cies. The second item, the two-headed 
machine, was almost entirely a software 
project, since it consisted of new parallel 
software running on the same hardware 
platform as the single-headed machine. 
This made the hardware resources avail¬ 
able to finish the four-headed machine, 
which was entirely a hardware project, 
since it ran, unmodified, the previously 
released parallel software. 

This amounted to formal recognition of 
something management knew very well: 
The Cl was aging rapidly. There would 
surely come a day when the Cl could not 
meet the company’s sales objectives. 

In a large company with many products, 
delays in availability of a single product 
will not be fatal. Not so in a small, single¬ 
product company inhabiting an extremely 
competitive marketplace. We were making 
tactical decisions to minimize this risk by 
getting something that would replace the 
Cl as soon as possible, even if it delayed 
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(and it did) availability of the complete and 
final C2 product. 

In our naivete we had assumed that 
routing the boards would be a major prob¬ 
lem. We had designed our chip placement 
strategy to maximize routability. How¬ 
ever, the issue that actually drove chip 
placement was circuit delay. Timing verifi¬ 
cation of the partitioned design showed 
massive violations, so as partitioning 
began its next iterations, we set our sights 
on a design that would work, fit, and meet 
the required timing margins when parti¬ 
tioned. As the days and weeks went by, we 
sometimes thought we had on our hands 
an example matching the classical defini¬ 
tion of the over-constrained problem. 

The marketplace had continued to 
develop, of course. Cl was getting older 
and the start-ups kept emerging. Eighteen 
months into the program we still had 
no prototype. Management was con¬ 
cerned—to put it mildly. But we’d run out 
of compromises and had no choice but to 
finish the product we had started. 

F inally the logjam broke. One after 
another, boards were shipped to 
the vendor. Our multi wire routing 


tools were well developed, and once a 
board passed timing verification, we could 
route and ship it in less than a week. Gate 
arrays, programmable array logic devices, 
and other components were stockpiled in 
quantity. 

In late July of 1987 the first prototype 
system was powered on, and we began to 
discover the differences between the simu¬ 
lated interfaces to the service processor 
and the real interfaces. For several weeks 
we ground along, getting initialization and 
scan sequences right. Then we ran the first 
diagnostic. Six weeks later we were trying 
to boot the operating system. In another 
month we were running benchmarks. 

A lot of work remained, but now we 
were on a roll. Manufacturing was build¬ 
ing machines, and in the next six weeks 
several hundred benchmark codes ran. 
The beta machines shipped at Christmas, 
and production shipments started the next 
quarter. This is where the Cl compatibil¬ 
ity strategy really won. With very few 
exceptions, Cl applications ran unmodi¬ 
fied on the C2. 

Project start to beta shipment took just 
27 months, and 20-plus production units 
shipped the first quarter. This enabled 


Convex to counter faltering Cl sales with 
the C2, propelling us on a new wave of 
growth. And the design methodology 
allowed C2 engineers to turn the project 
over to manufacturing and get on with the 
C3 project. □ 
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EDS, the world’s leader in computer services, is seeking 
software research scientists to join an established Research and 
Development organization in Auburn Hills, Michigan. Our 
mission is to expand the business opportunities of EDS in the 
information services industry through the development and 
innovative application of technology. Applicants should have a 
Master’s Degree or Ph.D. in computer science, applied 
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► Productivity Tools for ► Animation and Graphics 
Software Engineering ► Human-Computer Interaction 
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Department offers B.S., B.A., M.S., and Ph.D., in computer 
science, and Ph.D. in management jointly with Rutgers-New- 
ark. Computing facilities include VAX 8800, VAX 8530, IBM 
4361, SUN workstations, Symbolics machines, Tl Explorers 
and graphics systems. 

NJIT is the comprehensive technological university of 
New Jersey with nearly 8,000 students enrolled in Newark 
College of Engineering, the School of Architecture, College 
of Sciences and Liberal Arts and the School of Industrial 
Management. 

NJIT does not discriminate on the basis of sex, race, color, 
handicap, national or ethnic origin, or age in employment. 
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Cray X-MP: 

The Birth of a 
Supercomputer 

Melvin C. August, Gerald M. Brost, 
Christopher C. Hsiung, and Alan J. Schiffleger 
Cray Research 


R eal machine design often is tedi¬ 
ous and painstaking and contains 
many unforeseen detours and 
compromises. The challenge is to set real¬ 
istic goals in the very beginning so that not 
much time is lost striving to meet those 
goals. Our experience designing and manu¬ 
facturing the Cray X-MP supercomputer 
exemplifies this process. 

In 1978, Lester T. Davis conceived of the 
X-MP as a multiprocessor design built on 
the basic architecture of the Cray-1 and 
incorporating the 16-gate emitter-coupled 
logic gate arrays used by Seymour Cray in 
his Cray-2 project. Davis stated that the 
goal was a two-processor machine compat¬ 
ible with the Cray-1 but with performance 
1.5 to 2 times better. 

Even though we built the X-MP on the 
basic architecture of the Cray-1, we totally 
redesigned it otherwise. The entire project 
team consisted of fewer than twenty profes¬ 
sionals, since we believe that small teams 
streamline decision making. This was pos¬ 
sible only because other departments 
helped in such areas as printed circuit 
boards, module assemblies, solid-state 
storage device designs, I/O subsystems, 



The Cray X-MP effort 
began with clear 
design goals that evolved 
as the team dealt 
with issues such as 
circuit design and 
compatibility with the 
Cray-1. 


and other peripherals. 

The complexity of the project also led us 
to use one of our own supercomputers in the 
design process for the first time. In the end, 
the Cray X-MP/2 exceeded its project per¬ 
formance goals. We concentrate in this 
article on some of the design trade-off is¬ 
sues that led to this result. (A detailed 
description of the X-MP itself can be found 
in other works. 1 ) 


Cray-1 

When the first Cray-1 was delivered to 
Los Alamos National Laboratory in 1976, 
its most revolutionary features were its 
register-to-register vector architecture and 
the chaining concept. 2 - 3 This new approach 
proved so much more effective than the 
first generation of vector/parallel architec¬ 
tures that it became the de facto industry 
standard for the second generation of super¬ 
computers. 

Several other factors in the Cray-1 de¬ 
sign contributed to its success. 4 The in¬ 
struction set was simple, and the logic 
design was compact, so there were no 
physically distinct scalar or vector units. 
The partitioning of the functional compo¬ 
nents was tightly knitted. This approach 
eliminated a lot of interface overhead asso¬ 
ciated with loosely integrated machines. 
The mechanical packaging was also com¬ 
pact, shortening the physical paths in the 
machine and contributing to the speed. The 
problem areas for a compact design with 
emitter-coupled logic technology involve 
interconnection and heat dissipation. The 
module design and Freon cooling technol- 


January 1989 


0018-9162/89/0100-0045$01.00©1989 IEEE 


45 








The wish list 

The following key performance-related issues guided our 
processor design. 

Memory ports. The one-port memory design of the Cray- 
1 can become a major bottleneck for some Fortran codes. 
For example, a simple vector loop 

DO 10 /=1,64 
10 A(l) = B(l) + C(D 

requires two vector reads to load arrays B and C and one 
vector write to store array A. Executing all these memory 
operations simultaneously on separate memory ports would 
be a lot faster than doing them sequentially on one memory 
port. 

Chaining. The Cray-1's fixed chain-slot-time scheme is 
inconvenient both for users and compilers. 

Executing related vector operations concurrently achieves 
more parallelism on the Cray-1. For example, in the vector 
loop above, assuming that array B is already loaded in a 
vector register, the vector loading of array C can occur 
concurrently with the floating-point addition. That is, the add 
operation can be performed on any operand pair as soon as 
the corresponding element in array C arrives in the vector 
register. This feature on the Cray-1 is called chaining, as 
illustrated below. 

load 6(1-64): I-1 

load 0(1 -64): |_| 

UWWWWU 

B+C: |-1 

store 4(1-64): I-1 

After the vector load operation of array 6 is issued, the 
vector add operation must be issued within a fixed number 
of clock periods, called the chain slot time. Otherwise, 
chaining will not occur, and the add operation will have to 
wait until the vector load completes. This artificial restriction 
exists because of the synchronous nature of the Cray-1's 
memory architecture. To exploit chaining, the compiler (or 
the programmer) has to make sure that the instruction that 
wants to catch the chain slot is issued early enough. This is 
cumbersome and not always possible. For instance, an 


instruction buffer fetch between the two instructions could 
destroy that chaining altogether. 

Gather/scatter. This feature allows vectorization of table 
lookup code, sparse matrix computations, and conditional loops. 

Many Fortran loops, such as some Monte Carlo codes, 
employ indirect addressing in their data structures. Many loops 
have IF-TFIEN-ELSE structures. Appropriate hardware support 
allows most of those loops to be vectorized. For example, a 
vector indirect addressing scheme can vectorize the following 
gather loop. 

DO 10 /=1 ,N 

10 A(l) = B(IND(/)) + C(l) 

Similarly, a vector indirect addressing mechanism can vectorize 
the scatter loop below. 

DO 10 1=1, N 

10 A(IND(/)) = B(l) + C(l) 

Without hardware support on the Cray-1, those loops executed 
slowly either in pure scalar mode or through a combination of 
vector and scalar operations. 

Block transfers. The Cray-1 blocks all other instructions from 
issuing when an address-cache or data-cache register block 
transfer is in session. This limitation is one of the Cray-1’s main 
scalar bottlenecks. 

Address and scalar registers. Providing multiple result 
paths for address and scalar registers eliminates unnecessary 
delays due to competition on a single data path. For example, 
even though an add and a multiply are unrelated, they may 
develop some conflict on the Cray-1’s single data path. 

Also, combining address and scalar registers into one set 
simplifies work for compiler writers. The fact that two sets of 
scalar registers exist in different word lengths creates complex¬ 
ity in register allocation, scheduling, and data movement 
between those sets. 

Vector masked store. Some conditional codes modify only 
partial data. In those cases, we want to store only those 
modified data. The lack of a masked store can make this 
process clumsy. 

Bit-reverse operations. This feature helps fast Fourier 
transform codes, such as signal and image processing, weather 
forecasting, and seismic codes. 


ogy of the Cray-1 were key factors that 
made the design work. (Kozdrowicki 5 of¬ 
fers a detailed discussion of the Cray-1.) 

Architectural 

considerations 

In typical Fortran code, the Cray-1 vec¬ 
tor architecture offered about a 5-to-l in¬ 
crease in vector speed versus scalar speed. 
We recognized that further improvements 
in vector speed would mean that scalar 
speed would increasingly limit total ma¬ 


chine performance. 6 8 Instead of pursuing 
multiple vector pipes, which would further 
increase vector speed, we decided to make 
the new computer a multiprocessor design 
to enhance scalar speed. Another critical 
design feature and the most expensive part 
of the system was the memory. We could 
minimize this cost and more easily attain 
higher performance with a statically and 
fully addressable shared memory. 

Single CPU considerations. Based on the 
views of our software people and our cus¬ 
tomers, we compiled a “wish list” for the 


design of a single processor (see accompa¬ 
nying sidebar). We used this list as a guide 
for our design considerations. Figure 1 
shows the general organization of one X- 
MP CPU. 

Memory issues. We knew from looking 
at any vectorizable Fortran code that the 
memory port issue deserved our first atten¬ 
tion. Also, our goal of designing a multi¬ 
processor dictated a drastic change over the 
Cray-1, since the memory would need to 
support more than one processor. We could 
achieve this with either a single, shared, 
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Figure 1. Cray X-MP system organization. 


higher bandwidth memory port or an inde¬ 
pendent memory port for each processor. 

The single-port concept had three draw¬ 
backs. The number of data paths to and 
from each register would increase to sup¬ 
port multiple words per clock period, thus 
increasing the module count. Also, chain¬ 
ing to and from memory would become 
difficult to support if the memory path used 
multiple words per clock period while the 
functional units used only one per period. 
Finally, strides other than one required a 
more complex address generation. 

Independent ports for each processor 


required either restricting simultaneous 
memory activity so that no conflicts would 
occur or handling gaps in the data stream 
caused by conflicts. The best solution ap¬ 
peared to be independent ports, but only if 
this design allowed chaining. Since we had 
to sacrifice the Cray-1 ’s synchronous and 
predictable memory-access operations, we 
needed a flexible chain slot time. Flexible 
chaining allowed simultaneous reading 
from and writing to a vector register. With 
additional logic, it also allowed chaining 
based on the availability of individual ele¬ 
ments. This feature allowed chaining at any 


point in the vector data stream, eliminating 
chain slots entirely. 

With this solution to handle independent 
ports for each processor, we could now 
expand the number of ports per processor. 
After determining the amount of logic we 
could afford, we agreed that each processor 
would have two vector load ports, one 
vector store port, and one I/O port. To 
handle read-after-write or write-after-read 
problems with multiple ports, we originally 
considered putting in conservative hard¬ 
ware checks. After much deliberation we 
decided to shift all of the data integrity 
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Figure 2. Basic organization of the four-processor system. 


burden to software, since we did not want to 
penalize vector memory access with 
nonunit strides (nonconsecutive access 
patterns) and since the hardware would find 
covering cases of vector lengths greater 
than 64 difficult. The hardware would only 
provide two protection features: “disable 
bidirectional memory” and “wait for 
memory traffic to be quiet.” Our decision 
did create some problems initially in com¬ 
piler-generated dot product code, where 
the read got ahead of the write in the final 
stage of collapsing the last 64 elements 
when no protection code was put in. The 
software solution was also simple. The 
compiler only had to issue an instruction 


that ensured that the write was done before 
issuing the read instruction. 

We encountered another major difficulty 
in trying to place chips on the printed cir¬ 
cuit board according to our scheme for 
memory-conflict resolution. For some 
critical areas, the original module design 
did not provide enough predetermined hole 
positions (jumper positions) for board-to- 
board connections on the module. Conse¬ 
quently, our artwork people spent a month 
vainly trying to lay out chips on the module 
that handled the multiport conflict check¬ 
ing. 

In the summer of 1980, we decided to 
pursue a simplified two-port version, in¬ 


tending to reconsider the problem later. We 
worked with the original jumper scheme 
until we had trouble designing the floating¬ 
point adder. We finally relaxed the design 
rules with a new jumper block and module 
construction that allowed more jumper 
positions. Adding more jumper positions 
helped shorten the foil length, which finally 
allowed us to meet the four-port design 
goal. We rewired the prototype to accept 
this final change in February 1982, two 
months before we were to ship the machine 
to our data center in Mendota Heights, 
Minnesota. 

How many banks does an interleaved 
memory require to support all the memory 
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requests? We handled memory bandwidth 
in a rather ad hoc way. Even though later 
simulations and real runs verified that the 
four-processor X-MP with 64 banks could 
deliver more than eight words per clock 
period without delay in a memory stress 
test, the formula we used to determine the 
number of banks was a rather intuitive one 
at the time: 

number of banks = (number of total 
ports) X (number of clock periods 
the bank is busy) 

We were fortunate that the memory 
bandwidth turned out to be adequate and 
that the fluctuation in real user environ¬ 
ments tended to be less than 5 percent. 

Compatibility. Compatibility is always a 
sticky issue the second time around, espe¬ 
cially if the first machine is successful. We 
immediately dismissed all features that 
would create serious difficulties with the 
existing instruction format, such as the 
combination of address and scalar registers 
into one set (see the sidebar). The single 
incompatible change we accepted made the 
vector instruction, VI <- - VI + FV2, work 
the way it was supposed to. On the Cray-1, 
this instruction modified V\ in an unex¬ 
pected fashion and was very difficult to 
duplicate with flexible chaining. Users had 
found ways to use this anomaly, however, 
so we received some unfavorable com¬ 
ments even for this simple change. 

Incompatibility between floating-point 
formats was also a serious concern. For 
example, we seriously discussed streamlin¬ 
ing the reciprocal unit and providing hard¬ 
ware support for the square-root function. 
Since the reciprocal unit and the floating 
multiply unit take up a lot of space, and 
since the Cray-l’s reciprocal logic was not 
as clean as it could have been, we investi¬ 
gated and simulated changes in arithmetic. 
The new hardware for the reciprocal algo¬ 
rithm would have taken a little over half the 
space of the old one and been slightly faster. 
However, we finally withdrew the new 
reciprocal unit because of bit-wise com¬ 
patibility concerns. We investigated a 
faster square-root hardware scheme piggy¬ 
backed to the reciprocal unit, but we gave it 
up partly because of compatibility con¬ 
cerns. We also investigated several float¬ 
ing-point rounding schemes and aban¬ 
doned them all for compatibility reasons. 

Changes that allowed upward compati¬ 
bility from the Cray-1 fared better. For the 
two-processor design, we ignored the re¬ 
quests for gather/scatter and masked vector 



Compatibility is always a 
sticky issue the second 
time around, especially if 
the first machine is 
successful. 


store facilities because few team members 
believed that these kinds of operations were 
used frequently enough to merit considera¬ 
tion. We finally incorporated gather/scatter 
in the four-processor design in 1984 be¬ 
cause of repeated requests by laboratory 
users. We did not put masked vector store 
in the four-processor design, but we did 
incorporate a new feature that rendered 
vector indices from the vector mask. The 
combination of this last feature with the 
gather/scatter supported the equivalent of 
the masked store function. 

We incorporated separate result paths 
for each functional unit to scalar registers 
and address registers and eliminated hold 
issue conditions for address-cache and 
data-cache register block transfers without 
much debate because those changes bore 
no compatibility concerns and had man¬ 
ageable hardware costs. 

Other enhancements. We incorporated 
some other features for different reasons. 
For example, we doubled the instruction 
buffers to 32 words to allow more library 
subroutines to fit in a single buffer. On the 
other hand, we shared the I/O ports among 
all processors out of necessity so that any 
processor could service any I/O interrupt. 

Interprocessor communications. How 

tightly should we couple the processors, 
and how should we arrange them? Our goal 
was to design a multiprocessor machine 
that would be effective at handling tightly 
coupled multiprocessing for single jobs; 
that is, a machine that would support fine 
granularity multiprocessing down to the 
loop level. For this reason, we measured the 
efficiency of interprocessor communica¬ 
tion against the vector speed and not the 
scalar speed of the machine. This guideline 
affected many of our design decisions. 

We quickly rejected the idea of a kernel 
processor that would handle all I/O re¬ 
quests and other operating system func¬ 
tions because of the single-point vulnera¬ 
bility, the major changes in software phi¬ 
losophy, and the added design complexity. 
The choice of a symmetric multiprocessor 
then became an easy, decision. 


We needed new hardware mechanisms 
other than memory to allow the processors 
to synchronize and communicate effi¬ 
ciently in a shared-memory environment. 
We definitely needed some kind of sema¬ 
phore registers for fast synchronization. 
We decided on a set of 32 binary sema¬ 
phores, since we could efficiently imple¬ 
ment the full function of counting sema¬ 
phores through the binary semaphores and 
shared registers. The memory, with 12 to 
14 clock cycles of latency, was too slow for 
passing data among tightly coupled multi¬ 
processors. Thus, we provided several sets 
of eight shared data registers and several 
sets of eight shared address registers for 
faster data passing across processors. One 
set of these shared resources, which in¬ 
cludes semaphore and shared registers, is 
called a cluster. Figure 2 shows the organi¬ 
zation of the four-processor X-MP, with 
the CPU communication section being the 
clusters. 

To provide operating system control, we 
made the assignment of clusters a privi¬ 
leged function. The operating system can 
assign any one or none of the clusters to a 
group of processors. When two or more 
processors are assigned to the same cluster, 
the processors can use the cluster for com¬ 
munication and synchronization. It was 
argued that the operating system should 
keep one set for its own use and share the 
rest among user jobs as needed. In practice, 
since at least two processors share a cluster, 
P /2 + 1 clusters should suffice, where P is 
the total number of processors. However, 
we wanted to encourage and support logi¬ 
cal multitasking on a single processor for 
debugging runs, as well as provide a single 
version library that supports both uni- and 
multiprocessing. We therefore decided to 
provide P + 1 clusters for a P-processor 
configuration. 

One particular cluster operation de¬ 
serves a closer look. We could have de¬ 
signed the semaphore registers to function 
as test-and-set, fetch-and-add, or wait-and- 
set operations. While each has its own 
merits, we chose the last option. A proces¬ 
sor waits for a single semaphore bit to clear 
and then sets the bit. This basic control 
mechanism includes a hardware interlock 
and can implement any of the other com¬ 
mon software synchronization mecha¬ 
nisms. 

This “busy wait” semaphore operation 
has an advantage over other similar inter¬ 
processor-exclusive access controls, such 
as the test-and-set operation: The hardware 
can detect whether a processor is waiting, 
so a waiting processor can be selected at the 
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next interrupt time to do other useful work, 
such as processing I/O commands. Further¬ 
more, the hardware can detect a deadlock 
condition. When all processors assigned to 
a particular cluster are waiting on sema¬ 
phores, that group of processors is dead¬ 
locked and a hardware deadlock interrupt 
to each of them is triggered. The governing 
system software can then resolve the dead¬ 
lock. This is useful not only in resolving a 
true deadlock situation but also in schedul¬ 
ing other useful work when deadlock is 
detected. 

The X-MP’s interprocessor-communi¬ 
cation mechanism allows the processors to 
send and acknowledge messages and to 
synchronize activities in a timely way. This 
mechanism enables the multiprocessors to 
execute the tasks of a single user code 
concurrently in a coordinated manner 
(multitasking). 9 We can exploit this added 
dimension of parallelism at the Fortran 
outer-loop level, for example, with the 
vector processing at the inner-loop level. 
The ability to simultaneously exploit these 
two levels of parallelism in one user code 
and in such a tightly coupled fashion 1011 
exceeds the capabilities of vectorization. In 
cases where the inner loop contains short 
vectors we have achieved speedups of more 
than 1.9 times the speed of a one-processor 
machine on a two-processor X-MP 1012 (we 
would expect a speedup of about 1.5 to 1.7 
times on a two-pipe machine). The multi¬ 
processor design also is more general than 
the multipipe design, since the former can 
handle loops that contain subroutine calls, 
whereas the latter cannot. Moreover, the 
additional CPU area required for multiple 
processors rather than multiple pipes is not 
significant. 

Even though multiprocessing is more 
complex than vectorization — because of 
the need for synchronization and its more 
complicated data-scoping issue — we hope 
that better programming tools will soon 
make it as easy to use and understandable as 
vectorization. 

I/O architecture concerns. We realized 
that the difference in bandwidths in the 
storage hierarchy grew as the processing 
speed increased. Even with the availability 
of the I/O subsystem, which controlled and 
buffered all I/O activities, we still needed to 
quickly move scratch data into and out of 
central memory in the background at run¬ 
time. During the X-MP project, Davis initi¬ 
ated a parallel effort to design a solid-state 
storage device. This effort turned out to be 
crucial to the success of the X-MP. 1211 1n 
fact, the concept has been adopted by al¬ 


most all supercomputer vendors. 

We used the device for four different 
purposes: (1) as the disk cache that buffers 
disk files, (2) as the fast disk for many 
permanent system files, (3) as a swapping 
device for job rolling, and (4) as a fast 
device used by user jobs for often-used 
scratch files at runtime. We anticipate the 
uses of the solid-state storage device will 
expand beyond their current scope. 

Electronic design rules 
and CAD 

Our initial goal for the clock period was 
10 nanoseconds, but we quickly changed 
that to a more aggressive 8.5 nanoseconds. 
On the surface, the logic design rules gov¬ 
erning latch-to-latch paths remained much 
the same as those of the Cray-1. For ex¬ 
ample, there were eight levels of logic be¬ 
tween latches, with loads allowed on each 
signal. However, the faster clock period, 
use of new 16-gate emitter-coupled logic 
gate array technology, and a new double¬ 
module concept dictated a totally different 
set of detailed design rules than those used 
in the Cray-1. 

We made many adjustments to incorpo¬ 
rate shorter foil lengths for latch-to-latch 
paths, minimize reflection problems, ac¬ 
commodate board-to-board connections on 
the module, improve signal quality for 
module-to-module connections, etc. We 
established the design rules through exten¬ 
sive testing and strictly enforced them with 
internally developed CAD tools through¬ 
out the entire design cycle. On the other 
hand, we made every effort not to overly 
restrict the logic designers with inflexible 
rules or CAD system constraints. 

On critical paths, we allowed exceptions 
under tight scrutiny to provide extra flexi¬ 
bility. For example, we had rules that gov¬ 
erned maximal distance (on the module) 
between the output pin from a chip and the 
edge connector going out of the module. 
Sometimes we could only place sending 
and receiving chips on different modules 
by allowing one of the chips to exceed the 
maximal distance of the design rules. In 
these instances the logic designer, the CAD 
engineer, and the two artwork people doing 
the chip placements met and allowed a 
relaxation of the design rules. They then 
modified the database containing the speci¬ 
fications of each module, so that a longer 
path for a sending chip on one module 
required a shorter path for the receiving 
chip on the other module. The total path 
was to correspond to the total path of the 
design rules; this was carefully measured 


and documented before approval. 

With 200 to 300 chips per module and 
thousands of latch-to-latch paths to check, 
the enforcement of design rules was not 
possible without automated aids. Cray- 
developed CAD-support software checked 
and enforced design rules at every stage of 
the design process. Functional-unit-level 
logic simulation reduced the number of 
design errors before we physically built the 
machine. 

The CAD effort smoothed the machine 
design process. Importantly to Cray Re¬ 
search, the X-MP project marked the first 
time we directly used one of our computers 
to design another. The complexity of the 
task required the use of the current genera¬ 
tion of supercomputer to design the next 
generation. From this experience, we 
learned that the CAD effort had to be part of 
the design team and that the needs of the 
logic design had to drive the CAD, not the 
other way around. 

The only major setback in the design 
rules was the relaxation of the clock period. 
Because of the 8.5-nanosecond clock pe¬ 
riod requirement, we did not allow latch-to- 
latch foils to exceed 12 inches. After nu¬ 
merous unsuccessful attempts to lay out the 
first module within the required path 
lengths, we relaxed the goal to 9.5 nano¬ 
seconds in 1980. 

We finally reduced the clock period to 
8.5 nanoseconds in 1986 by using faster 
circuits that were finally available. Conser¬ 
vative, strictly observed design rules in the 
original design phase made many such later 
improvements possible. This reaffirmed 
that a design team must develop a verifiable 
set of detailed design rules. 

Packaging, 
interconnections, 
and cooling 

The 16-gate emitter-coupled logic gate 
array chips used in the X-MP also affected 
the packaging because of the higher watt¬ 
age consumed and the tighter rules en¬ 
forced. The 16-gate chip could consume 
four to five times the power of a two-gate 
chip and thus create heat dissipation prob¬ 
lems if high-wattage chips were concen¬ 
trated in one area. To keep the junction 
temperature of the chip below 85 degrees 
Celsius, we automated power rules govern¬ 
ing chip placement. But, to shorten the 
signal travel time on the circuit board, we 
also could not place chips too far apart. To 
achieve a faster clock rate, stringent design 
rules also limited load clustering and the 
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number loads. These difficult factors 
made ex- 

tremely challenging, as illustrated in the 
following discussion. 

On the Cray-1, we mounted two standard 
6-by-8-inch circuit boards on two sides of a 
copper plate, as shown in Figure 3. The 
whole unit was called a module. Intermod¬ 
ule communication was carried through 
twisted-pair wires that were 3 to 4 feet long. 

We needed a tighter packaging technique to 
shorten signal traveling time. On the X-MP 
we used a double module consisting of two 
Cray-1-like modules sandwiched together, 
where all four circuit boards communi¬ 
cated through fixed locations via jumpers 
(see Figure 4). With so many interconnec¬ 
tions in the machine and thousands of paths 
to check, laying out a module was not an 
easy task, even with the help of the CAD 
tools. As mentioned earlier, only our re¬ 
laxation of jumper rules made the four-port 
design possible. Even though packing more 
and more power into the machine meant 
that cooling became more difficult, the 
whole area of interconnection — layer to 

layer, board to board, and module to mod- Figure 3. A Cray-1 module: two printed circuit boards and one copper plate, 
ule — was our most difficult packaging 
problem. 



Assembly. Not only do the Cray-1 and 
X-MP look alike as a whole, but a closer 
look reveals that the individual parts also 
look alike. This resemblance was deliber¬ 
ate; we decided early in the project to use as 
many common parts with the Cray-1 as 
possible and to make other parts appear 
identical on the assembly line. We were 
careful to make the assembly of the X-MP 
so much like the Cray-1 that the change 
would be transparent to our manufacturing 
people. Most of the components looked 
like their predecessors from an assembler’s 
point of view. We even packaged the inte¬ 
grated circuits in what appeared to be the 
same package. This approach worked so 
well that the manufacturing group built the 
X-MP prototype with a Cray-1 serial num¬ 
ber attached to it. There was virtually no 
learning curve for our manufacturing 
people, which is probably why they 
switched easily from building Cray-Is to 
building X-MPs. 

We achieved this transparency at the 
expense of more complicated design work. 
We had to handle more interconnections, 
more heat dissipation, and more power 
distribution without the changes being 
apparent. When we were finished, we had 
cold bars and cold plates that dissipated 
twice as much power as those in the Cray- 
1, power supplies that delivered twice the 



Figure 4. A Cray X-MP double module: four printed circuit boards and two 
copper plates. 
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power, and connectors that made the double 
modules work. The printed circuit boards, 
although of the same size, could handle 
more traces and had better distributed ca¬ 
pacitance and additional cooling features. 

Testing. One area that often receives 
little consideration when designing any 
product is testing. A whole range of testing 
and simulation occurred during the design 
phase. However, once the machine was 
built, nothing was fast enough to test it. 
Hence, we had to design and build test 
equipment that would later be manufac¬ 
tured and shipped with every machine. 

A lthough multiprocessing had 
been around for a long time be¬ 
fore the Cray X-MP’s debut, it 
had met with limited commercial success. 
Today, multiprocessing is becoming com¬ 
monplace in the industry, and the X-MP 
series is going strong, as demonstrated by 
the announcement of large-memory EA 
models in 1988. This is quite an accom¬ 
plishment in an industry as demanding and 
rapidly evolving as the supercomputer 
industry. It shows that, even with conserva¬ 
tive technology, architectural innovation 
and tight system packaging can produce a 
balanced, high-performance supercom¬ 
puter. 

The keys to the X-MP’s success were the 
combined efforts and expertise of the de¬ 
sign team and the management philosophy. 
Cray Research was willing to take risks by 
allowing us to explore innovative ideas and 
cross the boundaries of job descriptions to 
help each other. We made concessions to 
put the project first and not cling to our own 
ideas. We made sure not only that our own 
individual parts worked but also that parts 
we used from other team members worked. 
Simple as it might sound, this practice 
helped tie up the loose ends and allowed 
timely completion of the X-MP. Small, 
autonomous groups minimized formal 
check points and tight controls, which often 
choke innovation. This willingness to help 
was present throughout the company. For 
example, the design team depended exten¬ 
sively on the engineering department, the 
printed circuit board department, the inte¬ 
grated-circuit design team, and the manu¬ 
facturing department to make the Cray X- 
MP a reality. 
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A retrospective analysis: 

The TI Advanced 

Scientific 

Computer 


Harvey G. Cragon, University of Texas at Austin 
W. Joe Watson, Texas Instruments 


T he Texas Instruments Advanced 
Scientific Computer (ASC) proj¬ 
ect spanned two decades, from 
the first preliminary discussions in Janu¬ 
ary 1966 until the power was removed 
from the last operating ASC in February 
1986. This article describes a few of the 
design decisions that determined this 
machine’s architecture and implementa¬ 
tion. We explain why certain design deci¬ 
sions were made, with a retrospective 
evaluation. Details of the architecture are 
available 1 ' 3 , as are general descriptions. 4 ' 5 

For the central processor, we opted for 
hardware complexity as opposed to soft¬ 
ware complexity. Because the hardware 
designers best understood the behavior of 
the scalar pipeline, hardware interlocks 
were added that forced stage delays as 
needed such that sequentially dependent 
operations would yield the expected 
results. 

However, for the peripheral processor, 
we wanted to maintain flexibility of 
design. Given that we expected the life of 
the system to be at least 10 years, we 
wanted to be able to upgrade I/O during 
this period. Therefore, the I/O device con¬ 
trollers were implemented in software 
using what would today be called a RISC- 
like simplicity in the hardware and a result¬ 
ing complexity in the software. 

One interesting aspect of the ASC story 
dealt with the difficulty we had in project¬ 
ing the technology—particularly memory 
technology—that would be available dur- 



Looking back, the 
factors that went into 
the design decisions 
behind the ASC’s 
architecture and 
implementation teach 
us ways to 

successfully approach 
similar projects today. 


ing its development. Discussion of two 
aspects of the design critical to the success 
of the project—the design automation 
software that made the very complex, mul¬ 
tilayer controlled-impedance printed cir¬ 
cuit boards possible, and the development 
of the first vectorizing Fortran 
compiler—are beyond the scope of this 
article. 

Architecture 

Preliminary studies began in January 
1966 to investigate a next generation of 


high-performance computers and the role 
integrated electronics and new memory 
systems should play. The purpose of this 
study was to specify a computer that 
would supply high-speed, cost-effective 
processing for general-purpose scientific 
and seismic processing. Meanwhile, Dan 
Slotnick of the University of Illinois was 
making final plans for the Illiac IV. We 
conversed with Slotnick about high-speed 
machines, initiating a relationship that 
lasted many years. 

During our study, we gave serious con¬ 
sideration to the Illiac IV’s architecture, 
which seemed ideal for processing well- 
ordered arrays of data. In addition, the 
architecture was projected to have a rela¬ 
tively low production cost because of the 
replication of identical components for the 
processing elements. It seemed ideal for 
high-volume semiconductor manufac¬ 
turing. 

However, as we further evaluated the 
architecture, we became convinced it 
would encounter severe programming 
problems and, as a “general purpose” 
supercomputer, its performance would 
not be impressive. 

The other architecture considered was a 
pipeline machine. We were influenced by 
the CDC 6600, 6 the IBM 360/91, 7 and the 
work of Cotten 8 and of Senzig and 
Smith. 9 A literature search resulted in 
several notebooks of reprints, which 
became required reading for the project 
participants. 
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By the end of July 1966, we finally real¬ 
ized that the Fortran do loop was an auto¬ 
matic invocation of a vector operation and 
that a vectorizing Fortran compiler could 
be developed. We could think of no way 
to program an array machine in Fortran. 

The path was now set. We would accept 
hardware complexity for the certainty of 
a vectorizing Fortran compiler; we never 
regretted this decision. Two decades later, 
the search is still on for a programming 
paradigm for array machines. 

In the summer of 1966, we made 
another major decision: the ASC would be 
a multiprocessor with a central processor 
unit and a peripheral processor unit (PPU) 
(see Figure 1). We had observed significant 
performance improvements when we 
attached “vector boxes” or coprocessors 
to some of our earlier computers. Further¬ 
more, the CDC 6600 effectively used 
peripheral processor units. We felt this 
architecture represented a good way of 
providing relatively specialized processors 
for two major functions of the system: 
number crunching and running the oper¬ 
ating system. 

In our pursuit of this multiprocessor 
architecture, we evaluated a low-end IBM 
360 processor for the peripheral processor. 
We rejected it due to the low I/O capabil¬ 
ity it would provide, since scientific and 
seismic processing can be I/O limited. 

We established the word length of the 
CPU and PPU at 32 bits. Some argued in 
favor of 24 bits for cost reasons, but the 
eventual need for addressability and stan¬ 
dardization settled the issue. The CPU 
instruction format is similar to the RS 
(register-and-storage operation) instruc¬ 
tion format of the IBM 360. However, we 
used dedicated base, index, and general 
registers rather than the multiuse registers 
of the IBM 360. As we will describe later, 
the instruction format of the PPU was spe¬ 
cialized to support the operating system 
and particularly I/O. 


Central processor 

We envisioned the CPU as a deep pipe¬ 
line with clear demarcation between the 
instruction processor and the execution 
units. In addition, the CPU was to support 
both scalar and vector instructions. The 
various design decisions are discussed in 
the following paragraphs. 

Interface to memory. As shown in Fig¬ 
ure 1, the memory control unit (MCU) 


interconnected the major subsystems of 
the ASC. The MCU was organized as a 
two-way, 256-bit-per-channel parallel 
switch between eight independent proces¬ 
sor ports and nine memory buses. Port 
expanders were employed on the user side 
of the MCU for relatively low bandwidth 
users such as magnetic tapes and disks. 

Each user port could support a transfer 
rate of up to 80 million words per second. 
With eight user ports operating concur¬ 
rently, the total bandwidth available was 
640 million words per second. 

Arithmetic pipeline. We did not use the 
dedicated function pipeline concept of the 
CDC 6600. Instead, we chose a single pipe¬ 
line design that could be reconfigured by 
a form of microcode to perform the vari¬ 
ous arithmetic functions. Figure 2 illus¬ 
trates how the pipeline can be configured 
for four typical functions. 

Several factors helped us make this 
design decision. First, we were not confi¬ 
dent we knew the frequency of occurrence 
of the various operations and could intel¬ 
ligently select the mix of dedicated pipe¬ 
lines. Second, if we guessed wrong on the 
frequency of occurrence, hardware might 
be wasted with unused pipelines or might 
be in short supply with heavily loaded 
pipelines. Third, we believed the vector 
lengths would be very long and the recon¬ 
figuration time would not be a significant 
overhead. 

The first system configuration consisted 
of one pipeline. However, we soon realized 
that one pipeline would not provide high- 
end competitive performance. Therefore, 
we expanded the system design to accom¬ 
modate one, two, or four pipelines, con¬ 
trolled by a single instruction processing 
unit. This system design change would not 
have been practical with fixed function 
pipelines. 

Vector instructions. After deciding the 
Fortran do loop was the programming 
access to the pipeline, we decided to embed 
the do loop statement in the hardware. 
Rather than the more prosaic Do instruc¬ 
tion, we called this class of functions “vec¬ 
tor instructions” after the mathematical 
vector. 

As described previously, the memory 
system had a data bus width of eight words 
(256 bits). Thus, in one memory cycle, 
eight words, or an “octet,” would be 
available to the processor. A general vec¬ 
tor instruction in the instruction stream 
would fetch an octet that contained all the 
parameters of the vector instruction. 



Figure 1. ASC system organization. 
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Figure 2. Four functional configurations of the ASC arithmetic pipeline. 


including the operation code. 

Figure 3 shows the vector parameter file 
and vector flow chart. Dedicated address 
arithmetic hardware would generate the 
three vector address streams concurrent 
with processing. Thus, the pipeline(s) 
could stream at the clock rate. Put another 
way, a specialized instruction buffer did 
not need to be serially decoded, as was the 
case in the CDC 6600 instruction buffer. 
Still another way of looking at this design 
decision is that we moved the address 
arithmetic functions from the execution 
unit subsystem, as in the CDC 6600, to the 


instruction processing unit. 

The octet contained the operation code; 
starting addresses for the A, B, and C vec¬ 
tors; and the increment values for the inner 
and outer loops (16-bit signed integers). 

The first loop, called the self loop, 
would increment or decrement. With this 
addressability, a three-dimensioned array 
could be processed with one vector instruc¬ 
tion. As the length and increment of each 
vector was known, the hardware could 
schedule the fetches of the operands from 
memory without bubbles in the pipe. After 
fetching the vector parameter file, no fur¬ 


ther reference to memory was required for 
instruction fetches. 

We now believe this architectural fea¬ 
ture, as implemented, was only a qualified 
success. An arithmetic unit for scalar 
instructions would have permitted the con¬ 
current execution of scalar and vector 
instructions, since the memory bandwidth 
was sufficient to support both operations. 

Vector hazards. On long vector opera¬ 
tions, read-after-write hazards can exist in 
main memory if the results of a vector 
operation are stored in the same addresses 
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HS Half word start address 

VI Vector increment direction 


Figure 3. Vector parameter file and flow chart. 


as the source vectors. Since vector opera- 
I tions are of the early binding type, we 
elected to have the detection and reso- 
[ lution mechanisms in the software. 

Scalar instructions. While our major 
design considerations focused on high- 
i performance vector instructions, we were 
concerned with the scalar performance as 
well. We understood the consequences of 
| Amdahl’s law on the speed improvements 
I possible by increasing vector processing 
rates. As we became more knowledgeable 
about the high scalar content of many 


scientific programs, we found more atten¬ 
tion should have been given to scalar per¬ 
formance. 

The low level of circuit integration avail¬ 
able to us limited the amount of instruc¬ 
tion buffering possible. Our analysis of 
buffer size studies from Stretch 10 led us to 
believe 16 words would be the optimum. 
This buffer was divided into two octets, 
each of which could be loaded in one mem¬ 
ory cycle. While the processor was work¬ 
ing out of one buffer, the other could be 
loaded from memory. 

Even though long vectors would be pro¬ 


cessed in the vector mode, efficient loop¬ 
ing was required, so we looked at delays 
due to branches. We incorporated “Load 
lookahead” and “Prepare to branch” 
instructions that the compiler could insert 
to select the octet to be loaded, reducing 
the penalty on branches that had a high 
probability of being taken. We also incor¬ 
porated a special adder in the instruction 
processing unit to provide for resolving a 
branch of the “Branch on register greater 
than” type in a shorter time than would be 
required if the arithmetic pipeline were 
used. This technique has come to be 
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known as “fast compare.” 11 

Even with these boosters to scalar per¬ 
formance, with the slow memories avail¬ 
able to us and the long pipeline, the 
average scalar-instruction time was six 
clock cycles—not a spectacular level of 
scalar performance. 

Scalar hazard detection and prevention. 

Unlike vector hazards, scalar hazard 
detection and resolution is performed in 
hardware. This is a function we did not 
want to place on the software; late bind¬ 
ing was considered more appropriate. The 
hardware checked for hazards in the reg¬ 
ister files used for data, indexes, and base 
registers. Multiple register files for these 
functions reduced the hazard checks 
required in systems that have a shared 
function register file. In addition, hard¬ 
ware was also included to check read-after¬ 
write hazards in the main memory for sca¬ 
lar operation. 

Checkout and maintenance logic. The 

checkout of a machine with the complex¬ 
ity of the ASC presented difficulties. The 
number of pipeline stages was high, the 
data paths were wide, and the logic com¬ 
plexity would be significant. 

To solve this problem, we adopted the 
strategy of providing a special main¬ 
tenance bus to all registers and flip-flops 
in the CPU. To use this facility, the clock 
would be stopped and the contents of all 
registers would be transferred to a special 
area of memory and selectively displayed 
on the console CRT. Thus, a clock-by¬ 
clock trace of all registers and flip-flops 
could be generated. 

If desired, one stage of logic could be 
checked by entering values into the 
upstream register via the bus, stepping one 
clock, and reading the contents of the 
downstream register. This is similar to the 
Scan Path technique used today in VLSI 
circuits. 12 

Peripheral processor 

The peripheral processor was designed 
to perform several tasks: 

(1) Execute the operating system and 
schedule the CPU. 

(2) Communicate with and control 
peripheral devices. 

(3) Provide central control for opera¬ 
tional checkout and maintenance. 

Task (2) will be discussed in the following 
paragraphs. 



The memory design 
effort was completely 
successful. 


Peripheral control. Our previous com¬ 
puters used special-purpose hardwired 
controllers. Each controller contained a 
custom design that resulted in high design 
and manufacturing costs. 

Late in 1967, Joe Watson and Ed Hus¬ 
band developed the idea of using the high¬ 
speed PPUs as programmable controllers 
that could provide bit-level control signals 
to the various I/O devices. Thus, the spe¬ 
cific control of a device was represented by 
a program. To provide control at the bit 
level, the PPU could read, write, and test- 
and-set individual bits in an array of bits 
called the communications register unit 
(CRU). This idea resulted in US Patent 
3,720,920. 

The PPU controlled and managed the 
data transfer of the low-speed peripheral 
devices such as card equipment and the 
operator’s console. For the higher speed 
devices, data transfers to and from mem¬ 
ory used special channels and controllers, 
as shown in Figure 1. 

The PPU departed in concept from the 
CDC 6600 PPU in two other significant 
ways. First, the ASC PPUs shared main 
memory with the CPU for high-bandwidth 
data transfers to and from the disk. In con¬ 
trast, the CDC 6600 has a private memory 
for each PPU. 

Our reasons for this approach were: 

(1) the large main memory would 
remove limits on program size 
found in a private memory system, 

(2) coherency problems would be 
avoided, and 

(3) high bandwidth memory could 
probably be provided easier in the 
one large main memory. 

A private read-only instruction memory 
of 4 Kwords was also included in the 
peripheral processor. This fast memory 
(25 nanoseconds) held device service rou¬ 
tines that would be infrequently changed, 
would have faster access than main mem¬ 
ory, and would reduce the bandwidth 
demand on main memory. 

The PPUs also differed from the fixed 


time slot assignment method of the CDC 
6600. There were eight PPUs and a time 
wheel with 16 assignment slots. The oper¬ 
ating system would place the name of a 
PPU in each time slot and, as the wheel 
rotated, the named PPUs would receive 
access to the ALU. 

Thus, a PPU could have access to the 
ALU between zero and 100 percent of the 
time, in increments of l/16th of total time. 
One PPU, zero, was hardwired into time 
slot zero to provide for cold starts. Assign¬ 
ments of names to time slots was a privi¬ 
leged instruction available only to PPU 
zero. In practice, this system was proba¬ 
bly too complex. One assignment seemed 
most effective, and it became a default 
assignment that never changed. 

The PPUs ran polling loops. Interrupts 
were not used in the PPU because we felt 
there was little to be gained by stacking 
interrupts when service could not be 
provided. Thus, we could poll bits in the 
CRU if needed only when time was avail¬ 
able for service. We believed this approach 
gave us a more deterministic system with¬ 
out penalties in either latency or processor 
resources devoted to asynchronous events. 

The CPU had two interrupts: an 
unmaskable power-going-down interrupt 
and a maskable arithmetic-exception inter¬ 
rupt. Power going down is an event that 
must be serviced, since the state of the 
machine needs to be saved on the disk. In 
our opinion, this is still a valid approach 
to servicing asynchronous events. 

System simulation. We developed 
several software systems to support ASC 
design and checkout. The first of these was 
a functional unit simulator to verify the 
architectural concepts and the detail design 
of each of the functional units. The second 
was meant for diagnostic use after the 
machine was built. 

These systems were coded in IBM 360 
assembly language. Since large-scale com¬ 
puter resources were scarce in the late 
1960s, these programs were run during the 
night on an IBM 360 at Texas A&M Uni¬ 
versity. We operated our own shuttle air¬ 
line to transport engineers back and forth 
for the simulation runs. 

Disk system. The disk system was 
designed with the following consideration 
in mind. Milo Backus envisioned a transi¬ 
tion from batch to interactive processing 
of seismic data. That is, a geophysicist 
would have a number of color displays 
that presented various maps and cross sec¬ 
tions of the earth. With a high- 
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performance computer, he or she would 
interactively manipulate the data, observ¬ 
ing the results on the displays. After 20 
years, such machines are only now becom¬ 
ing available at relatively low cost. 13 

To meet the needs of interactive process¬ 
ing, the high performance of the ASC 
processor had to be supported by a very 
high bandwidth, low-latency mass-storage 
device for rapid paging of data in and out 
of main memory. This requirement led us 
to develop a very large head-per-track 
disk, since no commercial disk met the 
requirements. Developing this disk was a 
multiyear effort that yielded impressive 
results. 

High bandwidth demanded a large 
number of heads to read or write the 32-bit 
word in parallel. Low latency demanded 
that 

(1) there be no mechanical head move¬ 
ment and track selection be com¬ 
pletely electronic, and 

(2) the rotation rate be as high as 
possible. 

The final design consisted of seven 32-inch 
platters on a horizontal shaft rotating at a 
rate of 1,800 revolutions per minute. Each 
platter had 448 read/write heads, the total 
storage was 100 megabytes, and the trans¬ 
fer rate was 2 megabytes per second. 
Development of this disk proved very try¬ 
ing, but was ultimately successful. 

Memory system. The main memory had 
to concurrently support 

(1) the pipeline(s) when streaming a 
two-operand, one-result vector, 

(2) the peripheral processors, and 

(3) the simultaneous transfer to and 
from two disks plus tape 
input/output. 

With the slow core memories of the day, 
this presented a significant design chal¬ 
lenge. A number of evolutionary steps 
took place in the memory system design 
before selection of the final technology 
and configuration. 

In the mid 1960s, the memory technol¬ 
ogy of choice for new high-speed com¬ 
puters was magnetic thin film. Bittmann 14 
reported on a 16-Kword, 500-nanosecond 
development at Burroughs. Similar work 
was in progress at Texas Instruments. One 
of the desirable features of this technology 
was that it favored a long-word organiza¬ 
tion; this was exactly what we needed for 
the ASC. 

The projected processor clock period 
was 60 nanoseconds, and a four-way, 
interleaved, 256-bit, 480-nanosecond 



Using error detection 
and correction proved 
to be a wise decision. 


memory would provide the necessary user 
bandwidth. Thus, we started the develop¬ 
ment of the thin-film modules for the sys¬ 
tem. The number of 256-bit words per 
module was set at 4 Kwords, giving us a 
total memory size of 128 Kwords. 

The schedule called for designing, 
fabricating, and testing the MCU and 
PPU ahead of the memory modules. 
Therefore, to provide a checkout memory, 
we purchased lower speed core memories 
(about 700 nanoseconds) and attached 
them to the checkout machine. To obtain 
the long word length, each module of thin- 
film memory required eight modules of 
core memory. 

Four of the thin-film memory modules 
were constructed, but they never achieved 
a satisfactory level of error rate and were 
abandoned. Thus, for a period of time, the 
core memory became the main memory of 
the checkout system. 

As the likelihood for success of thin-film 
memory diminished, our considerations 
turned to semiconductor memory because 
we felt core memory had run out of steam 
in terms of decreasing access time. Using 
semiconductors was very uncertain. We 
anticipated problems in power, error rates, 
density, and, above all, cost. 

Our first attempt at a semiconductor 
memory was the development of a 16 X 16 
array of static metal-oxide semiconductor 
cells (256 bits). Eight of these chips were 
interconnected on a ceramic substrate for 
a 2K x 1 array. Decoding was external to 
the array package. A prototype of this sys¬ 
tem was installed in November 1971. It 
proved inadequate. 

We then initiated two parallel efforts. 
First, because the main memory was still 
a problem, we undertook the development 
of a high-speed bipolar memory using the 
fully decoded 256 x 1 bipolar devices that 
were beginning to become available. This 
memory remained in production during 
the production life of the ASC. When 
1,024 x 1 devices became available late in 
the program, we reworked one system to 
use these devices. 


The second design effort was for an 
extended memory. By this time, we real¬ 
ized the head-per-track disk would not be 
completely satisfactory for paging, and we 
started developing an extended memory 
using the then-emerging 1103 lKx 1 MOS 
device from Intel and its Canadian licen¬ 
see. This memory occupied two cabinets 
and had a capacity of one million words. 
The memory design effort was completely 
successful and yielded a relatively fast, sta¬ 
ble extended memory system. 

Anticipating error problems with the 
semiconductor memories, we employed 
error correction codes. The main memory 
had single-error correction and double¬ 
error detection at the word level, making 
the total memory word length 312 bits. 
The extended memory used single-error 
correction and double-error detection at 
the octet level, resulting in a memory word 
of 266 bits. Using error detection and cor¬ 
rection proved to be a wise decision. 

As the transition to semiconductor 
memory was taking place, the concept of 
the four-pipe machine became active. As 
the processing rate increases, the I/O rate 
also increases. We believed we had under¬ 
scoped the I/O bandwidth requirement in 
the initial one-pipe system. Thus, we 
started developing the new memory system 
with the goal of an approximately 10-times 
increase in bandwidth. Two factors 
achieved this: the bipolar semiconductor 
memories had a cycle time of approxi¬ 
mately 160 nanoseconds, a five-times 
improvement; and the interleaving was 
increased from four to eight, a two-times 
improvement. 

To minimize the delay between the 
processor and the memory, we first opted 
for an asynchronous MCU. We lived to 
regret this design decision. We didn’t 
attain the anticipated performance, and 
we were plagued with data errors traced to 
the asynchronous interface and to syn¬ 
chronization problems. Later, we 
redesigned the MCU as a synchronous 
system. 

We made a major hardware commit¬ 
ment to the MCU. This subsystem con¬ 
sisted of two cabinets of circuits and two 
cabinets of connector panels (see Figure 4). 


Circuits and packaging, 
and cooling 

Circuits and packaging. In the mid 
1960s, emitter coupled logic was the 
highest performance circuit technology 
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Figure 4. Memory control unit. 



Figure 5. ASC printed circuit board. 


available. ECL selection played a direct 
role in a number of design decisions. 

The attainable circuit density with ECL 
was approximately six gates per package. 
Even at this low level of integration, power 
dissipation was between 0.05 and 0.6 watts 
per package. Furthermore, a controlled 
impedance (a combined 40-ohm, 80-ohm 
system) interconnection system was 
needed to connect the circuit packages. 

As a result of these considerations, we 
allowed a 7 x 9-inch 17-layer printed cir¬ 
cuit board for attachment of 154 packages 
on each side (see Figure 5). Solder pre¬ 
forms were used on each lead. A holding 
fixture kept the packages in place while the 
entire board was submerged in a “fondue 
pot” that melted the preforms and accom¬ 
plished the soldering operation. A 352-pin 
edge connector (272 signal, 80 power and 
ground) was developed, and a design auto¬ 
mation system was devised to place and 
route these boards. This major undertak¬ 
ing was very successful. 

Clock skew was a major design prob¬ 
lem. The system would occupy some 4,000 
square feet, and we wanted to limit clock 
skew to a few nanoseconds. Clock was dis¬ 
tributed from a central clock generator 
over equal-length coaxial cables coiled 
under the false floor. Clock was amplified 
and distributed up the cabinet to the 
motherboards and then through equal- 
length lines to the cards. On each card, a 
binary weighted delay line was modified to 
give a final adjustment to the delay. A 
binary-tree distribution system on each 
board delivered clock pulses to each quad¬ 
rant of the board. 

We rejected point-to-point wiring of the 
connectors as a means of reducing manu¬ 
facturing costs. This method limits the 
number of technicians who can work on 
the system at one time and can result in a 
significant buildup over the connectors. 
We had used this technique on our previ¬ 
ous computer (TI 870) and were resolved 
never to do it again. Therefore, we chose 
to have the cards plug into motherboards 
interconnected with preassembled wiring 
harnesses. These harnesses could be 
“buzzed out” and verified before final 
assembly (see Figure 4). This proved to be 
an effective design. 

Power supply and distribution. Each 
PC card dissipated an average of 100 
watts. A motherboard held 22 cards, and 
there were three motherboards in a cabi¬ 
net for an average of 6.6 kilowatts per 
cabinet. This power demand required two 
supplies, one at - 3.2 volts and the other 
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at 1.32 volts delivering 1,500 amperes. 
Two bus-bar systems running vertically in 
the cabinets provided a low-impedance 
distribution system. Each bus bar con¬ 
sisted of 3/8 x 5-inch aluminum bars lami¬ 
nated together with insulators. 

The initial plan was to mount the power 
supplies at the bottom of each cabinet. 
After several false starts, this proved 
impractical because of the limited space 
available. As a consequence, current sup¬ 
plies were housed external to the logic cabi¬ 
nets, and the low voltage was distributed 
to the logic cabinets via stranded 500,000 
circular mil copper cables (0.8 inches in 
diameter). Shunt regulators in the cabinets 
converted the two-wire current source to 
three wires ( + , - , ground). 

By today’s standards, an ASC con¬ 
sumed a lot of power. A single 128-Kword 
cabinet of high-speed main memory con¬ 
sumed 12,000 watts. The total system 
power requirement depended on the con¬ 
figuration; varied between 250,000 and 
350,000 watts. 

Cooling. As we designed the system to 
get power to the boards, we also worked 
on the thermal design to get the heat out. 
It is necessary to maintain a relatively uni¬ 
form temperature over the system or the 
threshold voltages of the ECL circuits will 
shift, degrading the noise margin. Low 
junction temperatures would make the 
system more reliable. 

Thermal mockups were built and tested. 
PC boards with resistive wire to dissipate 
power and thermocouples mounted in 
DIPs were installed in cabinets. From 
these tests, we quickly determined that 
forced-air cooling alone would neither 
adequately cool the system nor provide the 
uniform temperature needed. 

The solution was to interdigitate the PC 
boards with cold plates carrying chilled 
water. These plates had to be very thin to 
fit between the boards while restricting the 
flow of air as little as possible. Even so, 
they did increase the pressure required for 
the forced air. 

We first tried to supply the high- 
pressure air by pressurizing the subfloor. 
This did not work, since the floor panels 
tended to levitate. The final solution was 
to put individual blowers below each cabi¬ 
net. Most of the heat was removed by the 
chilled water because the exit air temper¬ 
ature was usually lower than the inlet tem¬ 
perature. 

Eighty tons of chilling capacity was 
provided for one ASC. Each cold plate 
required two gallons of water per minute, 


meaning a pumping requirement of 
approximately 100 gallons per minute for 
an entire system. 


Looking back 

Twenty-three years after the ASC design 
started, we think it is reasonable to won¬ 
der about the design decisions made. 
Which decisions have stood the test of 
time? Which decisions were incorrect? We 
will attempt to give some answers to these 
questions, knowing others may draw 
different conclusions from our 
experiences: 

• Technology issues: We were designing 
an integrated circuit supercomputer only 
eight years after Jack Kilby demonstrated 
the first integrated circuit. Thus, gates 
were relatively slow, and densities were 
low. 

With discrete transistor technology, 
Seymour Cray achieved a faster clock rate. 
But we believed integrated circuit technol¬ 
ogy was the wave of the future and did not 
want to use discrete transistors. 

The use of ICs was a correct decision. As 
discussed previously, the selection of a via¬ 
ble memory technology was difficult due 
to the rapid change in memory technology 
taking place at the time. The partitioning 
of the system permitted the memory per¬ 
formance to be upgraded when appropri¬ 
ate, using the latest in memory technology. 

The decision to embark on development 
of the head-per-track disk was not taken 
lightly. The difficulty of the development 
proved it would have been better if there 
had been a commercial source for these 
disks. We underestimated the large 
amount of power required for a fully con¬ 
figured system and the cooling problems 
that would result. 

• Multiprocessor configuration: Con¬ 
figuring the system into PPU and CPU 
sections was a good decision. When there 
is a special task to be performed, use a spe¬ 
cially dedicated processor. The use of a 
small single-chip microcomputer in the 
keyboard of today’s personal computer is 
an example of this configuration. 

As discussed previously, the I/O archi¬ 
tecture of the PPU has become a standard 
in personal computer systems. 

• Shared-memory configuration: This, 
we believe, was another good decision. 
With a crossbar switch, we could provide 
the required bandwidth to all the proces¬ 
sors from relatively, slow memory 
modules. 


We must concede, however, that the 
crossbar switch constituted a major invest¬ 
ment in hardware. We also believe the 
management and coherency control of a 
shared memory is simpler than the 
management of a number of smaller dedi¬ 
cated memories. 

• Vector instructions: This was a very 
good decision. As noted previously, with 
vector instructions we were confident the 
ASC could be efficiently programmed in 
Fortran. The alternative—an array 
architecture—was unacceptable due to 
programming problems. 

Having three loops (self, inner, and 
outer) in the vector instruction was prob¬ 
ably too complex; one hardware loop 
would have probably been satisfactory. 
We say “probably” because of the rela¬ 
tively slow scalar instructions; the time to 
do the loop arithmetic for the inner and 
outer loops might have been too long for 
relatively short vectors. Unfortunately, we 
did not create models that would have 
given insight into this type of design 
decision. 

• Scalar instructions: Scalar instruction 
performance was not satisfactory. Part of 
the problem was technology related; that 
is, the maximum instruction buffer size 
was 16 instructions. We believed this was 
satisfactory, but scalar performance 
would have been better if a larger buffer 
could have been provided. 

We provided assistance for looping, but 
did not consider any dynamic prediction 
strategy that would have reduced the per¬ 
formance impact of pipeline breaks from 
a taken branch. 

• 32-bit word and360-like instructions: 
The choice of 32 bits was obviously cor¬ 
rect. The anticipated cost savings with a 
24-bit word have been swept away by tech¬ 
nological advances, and the benefits of 
standardization are very real. 

The 360-like instruction format 
provided some slight advantage in the 
development of the compiler and operat¬ 
ing system. However, this advantage was 
not significant. The major advantage was 
the use of a regular format that facilitated 
the decoding process, a feature found 
today in most RISC-like processors. 

• Hazard detection and resolution: The 
issue of performing these functions in 
hardware or software is still hotly debated. 
But we believe our decision to use the hard¬ 
ware solution was correct, even at the cost 
of a larger number of gates and a small 
increase in clock period. Today, the gate 
cost is insignificant, and the increase in 
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clock period probably cannot be 
measured. 

• Reconfigurable arithmetic pipelines: 
This was almost a necessary design choice 
for an expandable system, since dedicated 
function pipelines would be difficult to 
expand. We see reconfigurable ALU inte¬ 
grated circuits today that perform logic, 
fixed-point, and floating-point arithmetic. 
These chips are used in much the same way 
we used the reconfigurable pipeline on the 
ASC. 

• Checkout and maintenance logic: If 
we had not devoted a significant amount 
of costly logic to this task, we might never 
have been able to check out the first ASC. 
The lesson to be learned from our experi¬ 
ence is that checkout and maintenance 
must be considered at the beginning of the 
system or VLSI-chip design. These con¬ 
siderations cannot be an afterthought. 

• Interactive systems: The decision to 
develop the ASC as a highly interactive 
system was wrong. The cost per calcula¬ 
tion was just too high then to make this 
type of processing cost effective. Further¬ 
more, just-emerging high-resolution dis¬ 
play technology was inadequate to meet 
the needs of the system. 

This decision was later reversed, and a 
very efficient batch operating system and 
vectorizing compiler were developed that 
permitted the ASC to be used at its full 
potential. 

T he ASC development was an 
exciting event. We explored many 
design alternatives in our search 
for the best architecture for a supercom¬ 
puter. In many designs, as we fought, the 
design fought back. But we succeeded in 
the end. Today, we believe most of our 
design decisions were good ones and have 
stood the test of time. 

As today’s microprocessor architectures 
are pushed for higher performance, many 
of the things we incorporated into the ASC 
are being used. It is good to see “old 
friends” again. 

Seven ASCs were constructed all told. 
ASC Number 1 was the prototype. ASC 
Number 2 was first installed in the Texas 
Instruments Seismic Center in Holland 
and subsequently installed for use in the 
Austin Seismic Center. Number 3 was 
delivered to the Army Ballistic Missile 
Defense Agency in Huntsville, Alabama; 
Number 4 was installed at the Geophysi¬ 
cal Fluid Dynamics Laboratory at Prince¬ 
ton University; and Numbers 5 and 6 were 
constructed for internal use in the Austin 


Seismic Center. ASC Number 7 was deliv¬ 
ered to the Naval Research Laboratory in 
Washington, DC. 

A number of artifacts of the ASC are on 
display at the Computer Museum in Bos¬ 
ton. The display includes a logic cabinet, 
a disk platter and heads, a cold plate 
assembly, and a logic card with its 
artwork. 

Because this project was executed within 
a single company during a time of rapid 
technological growth, we solved problems 
not only in computer architecture but 
problems in classical electrical engineer¬ 
ing, chemical processes, ceramics, MOS 
and bipolar semiconductors, acoustics, 
high-precision rotating machinery, aero¬ 
nautical engineering, heat transfer, and the 
software sciences of compilers, design 
automation systems, and diagnostics. □ 
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T he challenge of designing a micro¬ 
processor lies in finding the opti¬ 
mal balance within the “eternal tri¬ 
angle” of cost, performance, and schedule. 
Providing a balanced solution involves 
identifying the best trade-offs for both the 
microprocessor under design and the sys¬ 
tem applications it will support. 

In this context, we cannot achieve in¬ 
creased performance simply by packing 
more and more transistors onto the chip and 
running the processor at higher frequen¬ 
cies. An unbalanced trade-off that empha¬ 
sizes microprocessor performance alone 
without considering the system environ¬ 
ment can cut the user off from the device’s 
power and yield an unnecessarily costly 
and slow system. 

Instead, we need a global view of the 
system for correct functional partitioning 
between on-chip features and those placed 
in general-purpose support components or 
application-specific circuits. Functional 
partitioning maximizes system perform¬ 
ance while simplifying the interchip inter¬ 
faces at a minimized cost. Most impor¬ 
tantly, these design choices do not stop at 
the system architecture level, but repeat 
themselves in each design stage and for 
each section of the microprocessor. 

This article examines the performance, 
cost, and schedule trade-offs made for the 
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Any computer design 
effort must balance cost, 
performance, and 
schedule. General- 
purpose multiprocessors 
used in many different 
types of machines impose 
special challenges. 


NS32532, a 32-bit general-purpose micro¬ 
processor produced by National Semicon¬ 
ductor (see Figure 1). Among its features 
are 30-megahertz clock frequency, three 
on-chip caches, a four-stage pipeline, and 
dedicated mechanisms for multiprocessing 
support. 

The article is divided into six sections. 
We first describe the design constraints set 
by the VLSI processing and packaging 
technologies and then address the issue of 
market requirements by examining the 

A version of this article appeared in Proc. 22nd Hawaii 
Int'l Conf. on Systems Sciences, Jan. 3-6,1989, Kailua- 
Kona, Hawaii. 

0018-9162/89/0100-0066S01.0001989 IEEE 


software and hardware considerations for 
the microprocessor’s target applications. 
After describing the functional partitioning 
choices, including the means for support¬ 
ing a memory hierarchy and floating-point 
operations, we present the NS32532’s 
microarchitecture, including a description 
of the four-stage pipeline and on-chip 
caches. We then examine the 
microprocessor’s system interface, the 
memory reference transactions, and the 
instruction-flow and data-flow monitoring 
mechanisms. Finally, we present an over¬ 
view of the methodology adopted to ac¬ 
complish the design within a strict schedule 
while achieving full functionality and 
meeting cost and performance goals. 

Design constraints 

The NS32532’s specification was de¬ 
fined by National Semiconductor’s design 
engineers, architects, marketing personnel, 
semiconductor process and packaging spe¬ 
cialists, and customers. The perspectives 
and constraints of each of these groups 
became the base on which the performance, 
cost, and schedule trade-offs were made. 

Technology. The process team defined 
the technology constraints. Their goal was 
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to specify the semiconductor fabrication 
process and the packaging characteristics. 
Together, these defined the micro¬ 
processor’s size limits and the number of 
on-chip transistors. They also determined 
the switching speed for logic gates, the 
number of external pins, and the maximum 
power dissipation. 


Process. The process team decided to 
fabricate the NS32532 with complemen¬ 
tary metal-oxide semiconductor technol¬ 
ogy, a process that was becoming the indus¬ 
try standard. Earlier microprocessor gen¬ 
erations had been fabricated using N-type 
metal-oxide semiconductor technology, 
which is somewhat faster, more compact, 
and simpler to manufacture than CMOS. 
Nevertheless, CMOS shows lower power 
dissipation and better noise immunity than 
NMOS, essential characteristics for con¬ 
structing a microprocessor that integrates 
several hundred thousand transistors. 

Developments in semiconductor proc¬ 
essing technology proceed so rapidly that 
the design must allow for improvements 
from initial fabrication through volume 
production. At the time the design started. 
National had a 1.5-micrometer process and 
was developing a 1.25-micrometer proc¬ 
ess. We expected the 1.25-micrometer 
process would be in place two years later, in 
time for first fabrication of the NS32532. 
The process team decided to target the 
NS32532 toward the 1.25-micrometer 
process, but to leave open the option of 
fabricating the first parts at 1.5 microme¬ 
ters in case the more advanced process was 
not available in time. Consequently, the 
chip area was constrained by limitations of 
the manufacturing equipment for the 1.5- 
micrometer process. 

Some requirements of a 1-micrometer 
process planned to be available at the time 
of volume production also affected the 
design. We wanted to be able to use the 1- 
micrometer process without redesigning 
the microprocessor. As a consequence, we 
fashioned the tolerance of certain feature 
sizes beyond the requirements of the 1.25- 
micrometer process to ensure compatibil¬ 
ity with the 1-micrometer process. 

In the 1.25-micrometer technology, the 
chip size was set at 11.5 millimeters by 14 
millimeters (460 mil by 550 mil). This 
provided sufficient area for 370,000 tran¬ 
sistors. Simulations of the most critical 
circuitry carried out before detailed design 
indicated that the NS32532 could reach a 
frequency of 30 megahertz. 


Package. Advances in packaging tech- 


Figure 1. Photograph of the NS32532 microprocessor. 
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nology meant that the microprocessor 
would be able to access from 150 to 200 
external pins. This was a significant ad¬ 
vance from earlier microprocessors, which 
were limited to fewer than 100 pins. The 
requirement for more signals was driven by 
the need for greater communication rates 
with the system to achieve higher perform¬ 
ance. We allocated 129 pins for system 
interface, 39 for supplying power (and 
minimizing noise problems), and four for 
clocking. 

The package set a power dissipation limit 
of 4 watts, allowing designers to speed up 
critical circuit paths by applying pseudo- 
NMOS techniques (ratioed p- and n-chan- 
nel devices), which are faster but consume 
more current. These circuits consumed 
approximately 25 percent of the chip’s 
power. 

Market requirements. The corporate 
marketing group responsible for micropro¬ 
cessors identified product requirements 
and target applications before we started 
the design. These requirements defined the 
goals for the technical specifications devel¬ 
oped by computer architects in conjunction 
with VLSI designers at the earliest stages of 
the design. 

One of the primary decisions concerned 
the instruction set. The marketing group 
chose to maintain compatibility with two 
previous generations of the 32000 series 
microprocessors to support the existing 
customer base. The 32000 instruction set 1 
is characterized by a regular combination 
of operators, data types, and addressing 
modes. 

Instruction-set compatibility meant that 
an existing body of software would enable 
early introduction of products based on the 
NS32532. Compatibility also shortened the 
processor’s design schedule because the 
experience gained and computer-aided 
design tools developed during previous 
designs could be applied to the NS32532. 
Nevertheless, there was concern that in¬ 
struction-set compatibility might place the 
NS32532 at a competitive disadvantage 
with the performance available from newer 
architectures. Technical analysis showed 
that compatibility with the 32000 architec¬ 
ture would not limit the microprocessor’s 
performance if we used appropriate tech¬ 
niques in coordinated development of the 
microarchitecture and compilers. We pre¬ 
sent some of these considerations in the 
next section. 

One of the challenges characteristic of 
designing a general-purpose microproces¬ 
sor is to make it suitable for a wide variety 


of systems. A processor designed for a 
mainframe computer or minicomputer is 
usually targeted for a single system or a 
small group of related systems. In contrast, 
we designed the NS32532 for cost-sensi¬ 
tive embedded control products as well as 
performance-demanding multiuser sys¬ 
tems. When used to control a laser printer, 
for example, the microprocessor would 
have to support a closed system with a fixed 
set of peripheral devices, narrow (8- and 
16-bit) buses, and a memory built from 
relatively slow but inexpensive dynamic 
RAM. To support a multiprocessing com¬ 
puter for a large organization, the micro¬ 
processor would have to provide protection 
for multiple user tasks, support virtual 
memory, and operate with fast caches that 
present a coherent view of shared memory. 
The requirements of such divergent appli¬ 
cations influenced nearly all design 
choices. 

System-partitioning 

decisions 

The advanced technology available for 
the NS32532 meant that over 350,000 tran¬ 
sistors could be integrated to form the 
microprocessor. This provided sufficient 
resources for integrating some, but not all, 
of the essential elements for a microproces¬ 
sor system. The main functions considered 
for integration were caches, the memory 
management unit, the floating-point unit, 
and the cache controller. 

We considered each function for integra¬ 
tion according to its impact on system cost 
and performance in conjunction with chip 
area and compatibility constraints. The 
choices were evaluated for several systems 
(we will consider the previously mentioned 
laser printer and multiuser computer here). 

Before conducting the evaluation, we 
had to select a work load. We traced a 
collection of Unix system utilities, all writ¬ 
ten in C, along with several scientific appli¬ 
cations and benchmarks, most of them 
written in Fortran. In addition, a collection 
of kernel fragments for certain embedded- 
control applications were coded in assem¬ 
bly language. The high-level language 
programs were compiled with optimizing 
compilers developed for the 32000 archi¬ 
tecture. 2 One observation from this analy¬ 
sis showed that the frequency of instruc¬ 
tions and addressing modes for the hand- 
coded control applications resembled that 
of the HLL programs. The only significant 
differences were for bit and logical opera¬ 
tions and for multiplication, which oc¬ 


curred more frequently in some control 
applications than in any of the HLL pro¬ 
grams. 

Performance simulation showed that on- 
chip caches of 1.5 kilobytes can boost per¬ 
formance by approximately 50 percent for 
a multiprocessor system and 100 percent 
for a laser printer, which uses slower 
memory. We concluded that integrating 
such a cache on the chip would provide a 
valuable cost-performance contribution to 
systems in general. Further analysis, ex¬ 
plained in the next section, resulted in the 
design of separate instruction and data 
caches with capacities of 512 and 1,024 
bytes, respectively. Together, the caches 
accounted for 130,000 transistors and 25 
percent of the chip area, limiting our con¬ 
sideration of other components to integrate. 

Once we had selected the caches for 
integration, we examined whether they 
should be virtually or physically addressed. 
For several reasons, as explained in the 
following subsection, the functional re¬ 
quirements of many systems demanded 
physical addresses to access the caches. As 
a consequence, we also placed the memory 
management unit on the chip. This was not 
a difficult decision because the MMU used 
only 30,000 transistors and less than 10 
percent of chip area. 

The question of whether to incorporate 
an on-chip floating-point unit was influ¬ 
enced by the fact that many of the target 
applications had little need for floating¬ 
point arithmetic. Moreover, the size of a 
high-performance FPU exceeded the avail¬ 
able area. (The FPU considered would have 
used approximately 150,000 transistors. 
Although the number of transistors is close 
to that of the caches, the devices are packed 
much more densely in the cache memory.) 
We decided to concentrate resources in 
developing an efficient pipelined interface 
to an external FPU. 

We did not include the cache controller 
because its benefit did not span all applica¬ 
tions. Further, it was difficult to make it 
sufficiently general-purpose to meet the 
cache characteristics (degree of associativ¬ 
ity, memory-update policy, and line size) 
required by different systems. 

Memory hierarchy support. The on- 

chip caches are located at the highest point 
of the system’s memory hierarchy. The 
character of the memory hierarchy can 
differ greatly between systems. In cost- 
sensitive systems, for instance, the 
NS32532 can be connected directly to the 
main memory. In performance-demanding 
systems, the processor can be connected to 


68 


COMPUTER 








Cache memories 

Cache memories 1 2 are high-speed 
buffer memories used to hold copies of 
those portions of main memory 
currently in use. A processor can 
access information in the cache 
memory several times faster than the 
corresponding information in main 
memory. A cache memory attached to 
a processor also significantly de¬ 
creases contention with other bus 
masters (such as processors and 
direct-memory access controllers) 
when accessing the main memory, as 
most of the processor’s memory 
accesses are satisfied by the 
processor's private cache. 

The principle of locality explains why 
cache memories capture a large 
fraction of the main memory refer¬ 
ences in most cases. The cache 
locality has two aspects: spatial and 
temporal. Spatial locality means that 
the memory references of a program in 
the near future are likely to be near the 
currently referenced memory location. 
Temporal locality means that the 
currently referenced memory location 
is likely to be used in the near future. 

A good cache design should 
minimize the cache access time and 
the cache miss ratio (the percentage 
of memory refrences not satisfied by 
the cache). The cache design should 
also keep the cache contents coherent 
with the main memory and other 
caches to prevent the processor from 
using stale data. 13 

In single-processor systems, the 


cache coherence problem arises when an 
I/O operation modifies a memory location 
copied into the processor’s cache. 
Maintaining cache coherence is more 
complex in multiprocessing systems 
because several processors can read 
from and modify shared memory 
locations. Cache coherence can be 
maintained by software, hardware, or a 
combination of the two. 

Software can maintain cache coher¬ 
ence by selectively invalidating the cache 
and marking memory locations as 
noncacheable. Maintaining cache 
coherence entirely by software has 
several drawbacks: 

• The system is incompatible with 
programs developed without considering 
cache coherence. This problem can be 
critical for systems with an open architec¬ 
ture, where supplementing the basic 
system with additional software and 
hardware must be simple. 

• Errors can arise because there is no 
clear method for identifying in advance all 
the circumstances under which memory 
locations can be modified. 

• Performance can suffer because the 
cache is unnecessarily invalidated and 
restricted in its use. 

Hardware schemes for maintaining 
cache coherence are commonly based on 
a single system bus. The cache for each 
processor observes the memory writes 
performed by other processors and I/O 
devices; any copy of the modified location 
is invalidated or updated. Some systems 
use write-through caches so all memory 
modifications can be observed on the 
bus. Multiprocessing systems often 


an external cache. Because the on-chip 
caches would be called upon to work with 
various types of memory hierarchies, we 
needed to characterize the on-chip caches 
for correct and efficient operation with 
different systems. 

One key decision involved separating 
the data and instruction caches to increase 
the memory bandwidth over that available 
from a single cache and to avoid conflicts 
between instruction and data references. 
Another important design decision con¬ 
cerned the choice of using virtual or physi¬ 
cal addresses to access the caches. Al¬ 
though a virtually addressed cache would 
have been simpler to design, we chose 
physically addressed caches because they 
avoided problems associated with virtual 
aliases (two or more virtual addresses trans¬ 
lated to a single physical address). Addi¬ 


tionally, using physical addresses makes it 
unnecessary to invalidate the caches when 
switching tasks or at other times when the 
virtual-to-physical mapping is altered. 
Finally, our choice enabled the implemen¬ 
tation of techniques to ensure coherence 
between the on-chip caches and external 
memory. 

Ensuring the integrity of cached data is a 
primary concern of engineers designing 
systems around microprocessors with on- 
chip caches. Data integrity can be compro¬ 
mised when a direct-memory access device 
or another processor changes the value of a 
shared main memory location. Failure to 
update all microprocessors using that 
memory location will make the data in their 
caches inaccurate. The accuracy of cached 
data — cache coherence — is maintained 
by updating cached data as it is changed in 


implement more-complex bus 
protocols that support write-back 
caches, which can enable the use of 
more processors by reducing bus 
traffic. 

The on-chip caches of the NS32532 
are a major factor in achieving high 
CPU and system performance. 
However, these caches represent an 
extra level in the system’s memory 
hierarchy, which might consist of the 
on-chip caches, an external cache, 
and main memory. The NS32532 
design provides mechanisms for 
keeping this memory hierarchy (or a 
simpler one) coherent. 4 
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memory. The cache coherence problem has 
already been faced in systems constructed 
with off-chip caches. 

The NS32532 addresses the cache coher¬ 
ence issue by offering the system designer 
a choice between techniques based on soft¬ 
ware or hardware. The solution (or combi¬ 
nation of solutions) can be tailored to meet 
the system’s specific performance, com¬ 
patibility, and complexity requirements. 
We explain the cache coherence techniques 
in the section entitled “System interface” 
(also see the sidebar entitled “Cache memo¬ 
ries”). 

Floating-point support. The main dis¬ 
advantage of implementing the FPU on a 
separate chip from the CPU is the commu¬ 
nication overhead. The NS32532 mini¬ 
mizes the communication overhead by 
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Figure 2. Microarchitecture and system interface of the NS32532. 


Table 1. Performance factors. 


Performance 

component 

Cycles per 
instruction 

Ideal execution 

2.0 

Execution delays 

0.3 

Data dependencies 

0.1 

Control dependencies 

0.6 

Storage delays 

0.7 

Total 

3.7 


implementing a pipelined interface proto¬ 
col to an external FPU. One advantage of 
placing the FPU externally to the CPU is an 
increased range of cost-performance op¬ 
tions. The following are possible configu¬ 
rations: 

• No FPU. Floating-point instructions 
are emulated at no cost in software, but 
their performance is 50 to 100 times 
slower than integer operations. 

• A moderately priced, single-chip FPU, 
like the NS32381. Floating-point op¬ 
erations are approximately 10 times 
slower than integer operations. 

• A high-performance, multichip FPU, 
like the combination of NS32580 and 


WTL3164 chips. Floating-point opera¬ 
tions are executed as rapidly as integer 
operations. 

The NS32532-NS32580-WTL3164 
cluster implements the pipelined FPU 
protocol. 1 Up to five sequential floating¬ 
point instructions can be processed simul¬ 
taneously. The NS32532 sends instruction 
opcodes and operands to the NS32580 and, 
in most cases, continues to the next float¬ 
ing-point instruction without waiting for 
the instruction to complete. The 
instruction’s address (the CPU’s program 
counter) is saved within the NS32532 to 
enable correct instruction restartability for 
exception handling. The NS32580 receives 
the instructions and operands from the 
NS32532 and controls the WTL3164 float¬ 
ing-point data processor. 

Microarchitecture 

The NS32532’s microarchitecture is 
based on the system-partitioning decisions. 
It includes a four-stage pipeline connected 
to the MMU through a virtual-address bus 
and to the data cache through a data bus (see 
Figure 2). The pipeline also connects to the 
instruction cache through an instruction 
address bus and data bus. The pipeline 
executes instructions at an average 


throughput of 3 cycles per instruction in the 
absence of storage delays, and 3.7 cycles 
per instruction with typical hit ratios for the 
on-chip caches and zero-wait-state exter¬ 
nal memory (see Table 1). 

Instruction pipeline structure. The 

execution pipeline operates in four stages 
(see Figure 3): 

(1) Fetch instruction. 

(2) Decode instruction. 

(3) Calculate addresses and read source 
operands. 

(4) Calculate results and write destina¬ 
tion operands. 

The four stages are combined with three 
buffers to smooth the flow of instructions 
through the pipeline. An 8-byte queue fol¬ 
lowing the instruction-fetch stage buffers 
and aligns instructions of byte-variable 
length. A buffer following the instruction- 
decode stage can hold one fully decoded 
instruction ready for processing. Another 
buffer at the end of the pipeline can hold 
two results destined for memory. The re¬ 
sults are written when the bus is free, 
thereby permitting overlapped execution 
of instructions that read from and write to 
memory. 

The pipeline’s regular structure allows 
instruction fetching, data memory refer- 
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Figure 3. Pipeline structure of the 
NS32532. 



Table 2. On-chip caches. 



Instruction 

cache 

Data 

cache 

Total size 

512 bytes 

1,024 bytes 

Line size 

16 bytes 

16 bytes 

Associativity 

Direct-map 

Two-way 

Replacement 

N/A 

Least- 

algorithm 


recently-used 

Update policy 

N/A 

Write-through 


ences, and instruction execution to proceed 
in parallel. Data dependencies between 
instructions are automatically handled by 
hardware interlocks. The optimizing com¬ 
piler schedules instructions to minimize 
delays due to dependencies. 

Branch prediction. We examined sev¬ 
eral techniques for handling branches to 
sustain the pipeline’s instruction through¬ 
put. Branches and other forms of control 
transfer (procedure call, return, and jump) 
account for 23 percent of instructions in the 
work load. This results in approximately 
one of six instructions transferring to a 
nonsequential location. The penalty for 
taking branches in pipelined computers is 
heavy because all prefetching and pre¬ 
processing performed on instructions fol¬ 
lowing branches must be discarded. This 
penalty increases with the depth of the 
pipeline. The delay for control transfers 
would have been 0.9 cycles per instruction 
with no branch prediction mechanism. 

We considered numerous branch han¬ 
dling schemes from the literature for im¬ 
plementation. 4 Dynamic branch prediction 
techniques, where a table records the his¬ 
tory of encountered branches, showed suc¬ 
cess rates up to 90 percent, but only for 
tables of size comparable to the caches. 


Such solutions were too costly. Instead, we 
used a relatively simple static branch-pre¬ 
diction mechanism. The prediction is based 
on the direction (forward or backward) of 
the branch and the type of condition tested. 
The prediction, which is made as the in¬ 
struction is decoded, is correct for 71 per¬ 
cent of control transfers, resulting in a 
saving of 0.3 cycles per instruction. (Of the 
control delays, approximately 0.2 cycles 
per instruction arise from procedure re¬ 
turns. Such transfers can only occur after 
the return address has been read from 
memory, so the branch prediction mecha¬ 
nism is ineffective here.) 

On-chip caches. The NS32532 holds 
three on-chip caches (see Table 2): an in¬ 
struction cache, a data cache, and a transla¬ 
tion look-aside buffer within the MMU. 
The on-chip caches serve to reduce the 
average memory-access time. Access time 
is determined by three major factors: 

• cache hit ratio (the fraction of refer¬ 
ences located in the cache), 

• access time for hits, and 

• access time for misses. 

The designer controls these factors by de¬ 
termining the cache'size, organization, and 
replacement policy. Careful circuit design 
of the caches is essential to achieving fast 


access times. 

Simulations showed that a design with 
512 bytes of instruction cache and 1,024 
bytes of data cache would be balanced, 
delivering hit ratios of 82 percent and 84 
percent, respectively. The pipeline proved 
to be less sensitive to the hit ratio of the 
instruction cache than that of the data cache 
because prefetching and the use of burst 
transfers on the bus reduced the delay for 
external instruction fetches. 

Data cache. The data cache design goal 
was to provide a hit access time of one cycle 
and a miss delay of only two cycles. 

The data cache stores 1,024 bytes using 
a two-way, set-associative organization. 
The cache occupies 10 percent more area 
and has a miss ratio 20 percent better than 
a direct-map cache. Higher degrees of asso¬ 
ciativity presented difficult layout prob¬ 
lems and contributed less to performance 
than the step from direct-map to two-way 
associative. We chose a line length of 16 
bytes primarily because it suited the in¬ 
struction cache. A sub-block scheme is 
used where only 4 bytes need to be loaded 
on a miss rather than the entire line. We 
made this choice to reduce utilization of the 
external bus, especially for slower memory 
systems. 
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Figure 4 shows the organization of the 
data cache. Note that the valid bits are dual 
ported. We will explain the use of these 
ports for maintaining cache coherence in 
the next section. 

A write-through policy avoids cache 
coherence problems and simplifies im¬ 
plementation. A least-recently-used policy 
selects between the two banks of the data 
cache. 

The biggest problem in the data cache 
design was providing a hit access time of 
one cycle using physical addresses. We 
took advantage of the fact that the less- 
significant bits of the virtual address (in- 
page address) are identical to the physical 
address, llie virtual address for a source 
operand is simultaneously presented to 
both the translation look-aside buffer and 
the data cache (see Figure 5). While the 
TLB translates the virtual page address, the 
address tags selected by the low-order un¬ 
translated bits of the virtual address are 
read from the data cache. Following trans¬ 
lation, the physical address is sent simulta¬ 
neously to the cache and output pins, and a 
bus transaction is initiated. The two address 
tags from the data cache are then compared 
with the physical address. If there is a cache 
hit, the bus transaction is cancelled as indi¬ 
cated by a control signal pin. If there is a 
cache miss, the bus transaction to read the 
data from external memory continues with 
no delay caused by the presence of the on- 
chip cache. 

Instruction cache. The instruction cache 
is a 512-byte, direct-mapped cache identi¬ 
cal in design to a single bank of the data 
cache. The instruction cache derives much 
of its effectiveness from capturing loops, so 
the set-associative organizations show less 
improvement in miss ratio than they do for 
the data cache. 


To eliminate the need to translate the 
address for most instruction fetches, the 
physical address for the current page is held 
in the instruction cache. A reference to the 
MMU is made only when a code access 
crosses to another page. 

TLB. The 15-cycle delay for handling 
TLB misses is considerably longer than the 
delay for instruction or data cache misses. 
Therefore, a higher hit rate is required. The 
target was set to 99 percent, which we 
achieved with a 64-entry, fully associative 
TLB. 

A guaranteed translation time of 13 
nanoseconds was needed to achieve the 
data cache access in one cycle. We used 
power-consuming static circuits to achieve 
this goal. 

System interface 

The requirement that the microprocessor 
support a wide variety of applications 
strongly influenced the definition of the 
system bus interface. More specifically, the 
target systems’ cost-performance require¬ 
ments related directly to the highly differ¬ 
ing characteristics of their memory hierar¬ 
chies. As a consequence, the issue of on- 
chip cache memory was central to many 
design decisions. A straightforward ex¬ 
ample was the use of burst transfers on the 
32-bit data bus to enable a complete cache 
line to be filled in a single bus transaction. 
Other aspects of the decision to integrate 
caches on the chip influenced the use of 
techniques for efficient miss handling, 
cache coherence, and observing the inter¬ 
nal operation of the microprocessor. 

The NS32532’s system interface is rep¬ 
resented in Figure 2. The single-phase 
clock (CLK) input of the processor accepts 
a signal at twice the chip’s operating fre¬ 


quency (a 30-megahertz CPU requires a 
60-megahertz input clock). On-chip cir¬ 
cuits divide the frequency in half to obtain 
a two-phase (nonoverlap) internal clock. 
One of these phases is sent off the chip and 
forms the bus clock (BCLK). Most 
NS32532 timing parameters are specified 
relative to the BCLK edges. The timing is 
optimized for the convenience of the sys¬ 
tem designer. The supplied inverse of the 
system clock (BCLK) can minimize the 
clock skew in system timing. 

As explained previously, the integration 
of on-chip caches provides a performance 
boost across the target applications. The 
on-chip instruction and data caches can be 
accessed at the same time, in one clock 
cycle, by processing elements in the execu¬ 
tion pipeline. As a result, the peak NS32532 
internal transfer rate (memory bandwidth) 
is 240 megabytes per second at 30 mega¬ 
hertz. 

Nevertheless, the amount of cache 
memory we could place on the chip (1.5 
kilobytes total) was relatively small, and 
we recognized that the highest-perform- 
ance applications would use a large exter¬ 
nal cache in conjunction with the micropro¬ 
cessor. For such applications we needed to 
tune the access path for misses of the on- 
chip caches. We designed the bus to pro¬ 
vide the physical address externally as soon 
as the address translation is completed, 
thereby allowing access to an external 
cache to begin while the lookup in the on- 
chip cache is in progress. In the event of a 
on-chip cache hit, the bus transaction can¬ 
cels, indicated by a control signal pin. In the 
event of a cache miss, the bus transaction to 
read the data from external memory contin¬ 
ues with no delay caused by the presence of 
the on-chip cache. 

Cache coherence. When designing an 
on-chip cache for a microprocessor in¬ 
tended for a variety of system configura¬ 
tions, it is important to provide a flexible 
and complete set of cache coherence 
mechanisms. Software coherence mecha¬ 
nisms can be appropriate for small single¬ 
processor applications, where the cost of 
maintaining cache coherence with hard¬ 
ware is unacceptable. Hardware mecha¬ 
nisms are essential for shared-memory 
multiprocessing systems. 

As shown in Table 3, the NS32532 incor¬ 
porates several software and hardware 
mechanisms for maintaining coherence 
between its on-chip caches and external 
memory. 5 Coherence requirements of vari¬ 
ous systems can be accommodated by se¬ 
lecting the most appropriate mechanisms. 
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In software, pages can be marked non¬ 
cacheable, and a cache invalidation instruc¬ 
tion is available. When the instruction is 
executed, the contents of the on-chip in¬ 
struction and data caches are invalidated 
and status information is displayed on the 
microprocessor’s external bus. Another 
bus signal indicates when an off-chip ac¬ 
cess is to a noncacheable page. Thus, soft¬ 
ware can control an external cache in ex¬ 
actly the same manner as the on-chip 
caches. 

The microprocessor’s hardware-based 
coherence mechanisms include a bus of 
eight pins that controls total or partial in¬ 
validation of the on-chip instruction and 
data caches. Figure 4 shows the organiza¬ 
tion of the two-way set-associative data 
cache and its connection with the invalida¬ 
tion bus. Each of the cache lines within a set 
has an address tag, 16 bytes of data, and 
four dual-ported validity bits. Both lines of 
a data cache set can be invalidated using the 
invalidation bus. Because the validity bits 
are dual-ported, invalidation of the on-chip 
caches occurs without interfering with 
ongoing cache accesses or bus transactions. 

The NS32532’s hardware-based mecha¬ 
nism for maintaining cache coherence can 
be applied in a variety of ways. We present 
three examples here. In the first application 
(see Figure 6), the NS32532 operates in 
conjunction with an external bus-watcher 
circuit. The bus watcher observes the 
microprocessor’s bus transactions to main¬ 
tain a duplicate copy of the on-chip cache 
tags, while monitoring writes to main 
memory on the system bus. When the bus 
watcher detects that a location in the on- 
chip cache has been modified in main 
memory, it signals the microprocessor and 
sends the set number on the invalidation 
bus. 

In the second application, cache coher¬ 
ence is maintained without an external copy 
of the on-chip cache’s tags. This is accom¬ 
plished by connecting the invalidation bus 
lines that select the cache’s set number to 
the appropriate address signals of the sys¬ 
tem bus. Whenever a memory location is 
modified, the set where the location can be 
stored in the on-chip cache is invalidated. 
For example, when a write to location 4,096 
occurs, set number 0 is invalidated. This 
ensures that no copy of location 4,096 ex¬ 
ists in the cache, although copies of other 
locations (for example, 512 and 1,024) in 
the cache may have been unnecessarily 
invalidated. The performance impact of 
eliminating the bus watcher is minor when 
the rate of invalidations is much lower than 
the rate of memory accesses by the micro¬ 
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Figure 6. Cache coherence using a bus watcher. 


processor (this is the case for many single¬ 
processor applications). 

The third application is appropriate for 
multiprocessing systems and others that 
use an external cache with the microproces¬ 
sor. Coherence between the external cache 
and main memory is maintained using any 
scheme selected by the system designer, 
while the microprocessor’s invalidation 
bus is used to maintain coherence between 
the on-chip and external caches. To ensure 
the latter, it is sufficient to invalidate a set 
from the on-chip caches whenever a corre¬ 
sponding line in the external cache is up¬ 
dated or invalidated. 6 The external cache 
serves as a filter to keep potential invalida¬ 
tions on the system bus from affecting the 
microprocessor. 

External monitoring. Integrating cache 
memory improves a microprocessor’s per¬ 
formance by locating the majority of 
memory references on the chip. This per¬ 
formance benefit, however, renders invis¬ 
ible much of the microprocessor’s activity 
that would otherwise appear on its bus, 
making it more difficult to accomplish 
system debugging. Special mechanisms 
incorporated into the NS32532 overcome 
these potential limitations. 

The NS32532 displays information for 
each memory reference that appears on its 
bus, enabling an external copy to be main¬ 
tained for the on-chip caches and TLB tags. 
For example, for each cacheable data refer¬ 
ence, a signal shows into which element of 
the selected cache set the data will be 
placed. The NS32532’s on-chip caches can 


Table 3. Cache coherence mecha¬ 
nisms. 


Software 

Hardware 

Mark page 

Cache-inhibit 

noncacheable 

input signal 

Invalidate block 

Invalidate set 

if in cache 

in cache 

Invalidate 

Invalidate 

entire cache 

entire cache 


be disabled by software control of special 
bits in the processor’s configuration regis¬ 
ter. In addition, break points can be estab¬ 
lished upon reference to instruction and 
data locations that might hit in the on-chip 
caches and not appear on the external bus. 

System design examples. Figure 7 repre¬ 
sents a simple single-processor system 
using the NS32532. Because of the 
microprocessor’s high integration, the 
core-computing cluster consists of only the 
processor and a crystal oscillator. An op¬ 
tional FPU and/or interrupt control unit can 
be added to the computing cluster. The rest 
of the system simply consists of the main 
memory and peripheral devices (for ex¬ 
ample, disk and communication control¬ 
lers). If this single-processor system does 
not use a direct-memory access device, the 
on-chip cache coherence problem does not 
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Figure 7. Simple single-processor system using the NS32532. 


exist (only the CPU updates the main 
memory). However, if the main memory 
can be updated by a direct-memory access 
device, the on-chip cache coherence should 
be preserved either in software or (prefera¬ 
bly) in hardware without the help of a bus 
watcher. 

In a multiprocessor system, a large cache 
is usually attached to the CPU to minimize 
the system bus traffic. The memory hierar¬ 
chy in this case consists of the NS32532’s 
on-chip caches, the external cache, the 
main memory, and secondary memory 
(such as disks). Figure 8 represents a pos¬ 
sible multiprocessor system configuration. 
As previously explained, the coherence 
between the caches and the main memory 
can be preserved using a bus watcher 
mechanism. 

Design methodology 

The goal of the design methodology 
developed for the NS32532 was the con¬ 
struction of a highly integrated, high-per¬ 
formance device within a strict schedule. 7 
We met the goal by developing a hierarchi¬ 
cal methodology that relied on automatic 


and semiautomatic tools in the hands of 
approximately 30 design engineers. The 
methodology advanced that schedule at an 
acceptable cost in hardware and software 
development as well as chip size. 

The hierarchy allowed each block’s 
design to proceed independently of every 
other block. The design was done in several 
stages, with each providing a base for the 
next. A major aspect of each stage was 
testing a block for correct construction and 
coherence with other stages. Tests at the 
highest level ensured that design flaws 
were detected early. 

The use of automatic and semiautomatic 
tools for translating the basic block’s func¬ 
tional description to a layout ensured that 
errors did not creep in at the design’s lower 
level. This means the geometric patterns 
are placed on masks used during fabrica¬ 
tion of the microprocessor. 

High-level design. The high-level de¬ 
sign of the NS32532 described the micro¬ 
processor in terms of its major blocks and 
their interconnections. This stage pro¬ 
ceeded in two phases. First, the chip archi¬ 
tecture specification was translated to a 
behavioral description. Logic tests checked 


the correctness of the high-level structures 
and protocols. Second, the behavioral de¬ 
scription was broken down and translated 
to a hierarchy of functional units. The 
leaves of this hierarchy, known as basic 
blocks, were groups of random logic, pro¬ 
grammable logic arrays, or special struc¬ 
tures like an arithmetic logic unit or a reg¬ 
ister. Coding of this description was exe¬ 
cuted with a hardware definition language 
developed at National Semiconductor. 

Massive logic testing was performed on 
the microprocessor’s functional descrip¬ 
tion model. More than five million machine 
cycles were run prior to fabricating the first 
parts. The tests consisted mainly of ran¬ 
domly generated patterns with a high fre¬ 
quency of external events (like interrupts) 
and mixes of all instructions and address¬ 
ing modes. 

Low-level design. The low-level design 
was generated by translating the basic 
block functional description to layout. This 
stage was broken down into three steps. 

Step one identified the design restric¬ 
tions for each basic block. The setup time 
and input capacitances were estimated for 
each block’s input signals. Designers also 
estimated the valid time and capacitance 
load for each block’s output signals. 

A special computer-aided design tool 
calculated the required capacitance load on 
each signal and flagged contradictions be¬ 
tween the source and destination specifica¬ 
tions. These estimated timing and capaci¬ 
tance values were replaced by actual values 
after the lay^jit was complete. 

Step two translated the functional de¬ 
scription to a circuit description. Auto¬ 
mated synthesis tools used the interface 
specifications and hardware description 
language for creating the programmable 
logic array and random logic transistor 
descriptions. Automation ensured that no 
logic or speed flaws entered the design, and 
minimized other potential circuit prob¬ 
lems. All paths were automatically checked 
to determine whether they satisfied the 
speed requirements. 

Automatically generated random logic 
was 20 percent larger than manually de¬ 
signed logic. This sacrifice in area was 
justified by the savings in design time, 
which was shorter by a factor of three. 

Step three, which took place after the 
design was complete, verified the coher¬ 
ence between the low-level and high-level 
descriptions. Another computer-aided de¬ 
sign tool verified adherence to circuit de¬ 
sign methodology rules. 


74 


COMPUTER 








































Global memory 


Peripherals 


Figure 8. Multiprocessor system using the NS32532. 
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Layout. The layout for random logic, 
programmable logic arrays, and on-chip 
memories was created automatically. Chip- 
level routing was performed semiautomati- 
cally. While the automatic layout of the 
programmable logic arrays and memories 
was very efficient, the random logic layout 
and global routing optimization cost about 
10 percent in total chip size. Layout time 
for this activity was efficient. 

The chip size was minimized by manu¬ 
ally laying out the basic cells and the spe¬ 
cial structures. 

Postsilicon debug and correction. The 

role of the design methodology did not end 
with generating the masks for the first parts. 
The major vehicle for postsilicon logic 
debugging was a specialized functional 
tester developed at National Semiconduc¬ 
tor. The testing was based, as in the presili¬ 
con stage, on automatically generated ran¬ 
dom patterns with frequent external events. 
The frequency of events in this tester was 
about 1,000 times greater than in an actual 
system environment. Since the tests ran at 


full speed, their coverage was more exten¬ 
sive than the presilicon simulations. 

T he design of a general-purpose 
microprocessor must strike a bal 
ance among conflicting require¬ 
ments of performance, cost, and schedule, 
while adhering to technological con¬ 
straints. This balance cannot be based on 
the considerations of the processor alone, 
but must be made in the context of various 
system applications. Many important de¬ 
sign decisions concern the partitioning of 
system functions between those integrated 
on the chip with the processor and those im¬ 
plemented externally. More specifically, 
the decisions that concern integrating com¬ 
ponents of the memory hierarchy have the 
greatest impact on system performance, 
cost, and functionality. 
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Hewlett-Packard Company 


H ewlett-Packard designed Preci¬ 
sion Architecture to serve as a 
common foundation for its 
computer systems, to enhance software 
portability, to provide price-performance 
advantages, and to streamline the com¬ 
pany’s hardware and software develop¬ 
ment, manufacturing, and support 
activities. Prior to this, each of HP’s three 
major computer product lines, the 
HP3000, HP9000, and HP1000 systems, 
had different processor architectures, 
operating systems, and input-output 
systems. 

This article describes the processor com¬ 
ponent of the Hewlett-Packard Precision 
Architecture system, henceforth referred 
to simply as “Precision.” It describes the 
architecture’s goals, how the architecture 
addresses the spectrum of general-purpose 
user information processing needs, and 
some architectural design trade-offs. 

Goals. When HP charged the original 
architects with designing the new architec¬ 
ture, it presented us with some high-level, 
strategic goals. The architecture should be 
general purpose for use in commercial and 
technical applications. It should be scala¬ 
ble across technologies, cost ranges, and 
performance ranges and provide price- 
performance advantages. It should allow 
the leveraging of common hardware and 
software components. It should be 
designed with architectural longevity in 
mind, including features that enhance the 



The Hewlett-Packard 
Precision Architecture 
provides a simple, 
comprehensive 
foundation for 
general-purpose 
computer systems. It 
is scalable, efficient, 
and extendible. 


possibility of a long, useful life for the 
1990s and beyond. It should allow growth 
and extendibility. It should support mul¬ 
tiple operating environments, for exam¬ 
ple, single-user and multiuser, centralized 
and distributed computing, and conven¬ 
tional and object-oriented environments. 
It should support the implementation of 
highly reliable, secure systems and real¬ 
time environments. 


A version of this article appeared in Proc. 22nd Hawaii 
Int'l Conf. on Systems Sciences, Jan. 3-6, 1989, 
Kailua-Kona, Hawaii. 


For the processor architecture, the tech-. 
nical mapping of these strategic goals 
resulted in a simple RISC-like execution 
model 1 ' 3 with features for code compac¬ 
tion and dynamic path-length reduction, 
coupled with a more sophisticated set of 
extendibility and longevity features. 

Precision execution 
model 

For the execution model of the architec¬ 
ture, we mapped the scalability and price- 
performance goals into the following 
design guidelines: 

• Precision instructions should be 
executable in a single cycle with simple 
(pipelined) processor hardware. 

• Code compaction and dynamic execu¬ 
tion time reduction should be considered 
for frequently executed operation 
sequences. 

These guidelines resulted in an architec¬ 
ture where sometimes more than one oper¬ 
ation was performed in one instruction 
cycle, and other times only a part of a more 
complex operation was performed by one 
instruction. We based these design deci¬ 
sions on extensive measurements and 
studies of the frequency of operations and 
operation sequences. 4 ' 6 We made the 
basic assumption that high-level languages 
would be used for programming and that 
software and hardware would interact for 
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Figure 1. Typical system organization. 


the most efficient execution. 1,4,5 For 
example, we assumed the use of high-level 
language optimizing compilers for 
optimizing code generated from user 
programs. 


comprising an arithmetic logic unit (ALU) 
and a shift-merge unit (SMU). 

There are 32 general-purpose registers. 


where GRO is a constant zero source as well 
as a bit-bucket destination. While using 
more than 32 simultaneously addressable 


Figure 1 shows the modules in a typical 
system organization. Figure 2 shows the 
simple hardware needed for the execution 
unit. Figure 3 shows the registers, includ¬ 
ing the 32 general-purpose registers (GRs); 
the control registers (CRs), of which 25 are 
defined; the eight space registers (SRs); 
and the processor status word (PSW). I 
will describe the functions of these 
registers in the course of the article. 

Table 1 summarizes the instruction set 
in terms of the generic operations imple¬ 
mented per instruction. The 53 generic 
instruction types can be expanded to 140 
total instructions when we count all alter¬ 
natives and options. The data types sup¬ 
ported by the basic processor are signed 
and unsigned word, halfword, byte, 
packed and unpacked decimal numbers, 
8-bit ASCII, and 16-bit international 
characters. 

Simple hardware. The architecture has 
a general-register-based, load-store execu¬ 
tion model with a simple execution engine 



Figure 2. Execution data path. 
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General registers ^ ^ Control Registers 


GRO 

Permanent zero 

CRO 

Recovery counter (32) 

GR 1 

Target for ADDIL / General use 


Reserved 

GR 2 

General use 

CR 8 

Reserved (16) 

Protection ID 1 (15) 

WD 



CR 9 

Reserved (16) 

Protection ID 2 (15) 

WD 



CR 10 

Coprocessor configuration register 

GR 30 

General use 

CR 11 

Shift amount register 

GR 31 

Link register for BLE / General use 

CR 12 

Reserved (16) 

Protection ID 3 (15) 

WD 



CR 13 

Reserved (16) 

Protection ID 4 (15) 

WD 



CR 14 

Interruption vector address (32) 



CR 15 

External interrupt enable mask (32) 


0 31 

CR 16 

Interval timer (32) 

1 

Processor status word 

| CR 17 

IIA space queue (16/32) 



CR 18 

IIA offset queue (32) 



CR 19 

Interruption instruction register (32) 



CR 20 

Interruption space register (16/32) 


Space registers 

CR 21 

Interruption offset register (32) 


Link code space ID 

CR 22 

Interruption processor status word (32) 

SRO 

CR 23 

Fvtprnal intprrunt rpnup.Qt rpnictor lfiO\ 



Space identifier 




SRI 

CR 24 

Temporary register (32) 








Space identifier 





SR 7 

CR 31 

Temporary register (32) 


Note: Space registers are either 16-bit or 32-bit in length. 


Figure 3. Registers. 


general registers sometimes decreases the 
number of memory accesses, the trade-off 
yields an increase in the process swap time, 
in the number of bits needed to specify reg¬ 
ister addresses in an instruction, and in the 
area and access time needed for a larger 
bank of registers. Specialized register 
structures to improve procedure calling 2,7 
often have many hidden registers, incur¬ 


ring complexity without the advantage of 
making an increased number of simultane¬ 
ously accessible registers available to a 
good register allocator. 8 

Minimal decode instructions. To sim¬ 
plify instruction fetching and decoding, all 
Precision instructions are fixed-length 
32-bit words. This eliminates, for exam¬ 


ple, the complexity of handling page faults 
during the fetching of a single instruction, 
which can happen for variable-length 
instructions. 

Fixed-length instructions also enhance 
the use of fixed bit positions for time- 
critical operations, without waiting for 
decoding of the instruction. For example, 
since general register operands are always 
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opcode 
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•1 

opcode 

r 

r/i 

C 
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opcode 

r/cr/0 
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s/0 

e |m 

r/0 

opcode 

u 

opcode 
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sfu 

n 

u 

opcode 

u 

cop 
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u 



LD/STL 
LD/ST S/X 
COP LD/ST 
Long IMM 
BR 

ALU3R 

ALU Rl 

ALU F 

SYS 

DIAG 

SFU 

COPR 


specified by the two leftmost register fields 
in any register format (see Figure 4), the 
reading of general registers can occur in 
parallel with instruction decoding. The 
target register, however, can be in any one 
of the three register fields in different 
instruction formats. This is an acceptable 
trade-off since the processor has ample 
time to decode the target register specifi¬ 
cation. 

Combined operations. Many Precision 
instructions combine two operations into 
a single 32-bit instruction word. For exam¬ 
ple, in functional instructions (see Table 1) 
each instruction implicitly specifies an 
optional “conditional nullify” or “skip” 
feature in addition to the main arithmetic, 
logical, unit, or bit operation. In a single 
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cycle, as the data transformation opera¬ 
tion is performed, the condition specified 
in the instruction is also evaluated. If the 
condition evaluates to true, then the fol¬ 
lowing instruction is nullified. A nullified 
instruction has the effect of a NOP (no 
operation), with no changes to any 
architecturally visible state, including 
memory, and no side-effects like causing 
traps or nullification. 

Conditional branch instructions also 
combine two operations into a single 32-bit 
instruction by allowing simultaneously a 
functional operation to be performed on 
two registers, a condition to be evaluated, 
and a PC-relative branch target to be cal¬ 
culated, with the branch taken only if the 
condition evaluates to true. This again 
achieves code compaction, eliminates the 


need for storing condition codes in the 
processor, and enhances possibilities for 
reordering code in optimizing compilers. 

Combined operations reduce both static 
code size and dynamic execution time, 
since only one instruction is needed rather 
than two or more. 

Zero-cycle addressing and loading. The 

architecture makes extensive use of 
immediate data embedded within the 
instruction itself as one of the sources of 
operands. An immediate operand saves a 
memory load operation, provides effec¬ 
tively zero-cycle addressing, and does not 
require the use of a general register. Pre¬ 
cision immediates are unusual in that they 
are “maximal length,” that is, they fillup 
all unused bits in the fixed-length instruc- 
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Table 1. Instruction set? 


Memory Reference Instructions 

Load {Word/Halfword/Byte} 

{Long/Indexed/Short} [Modified] 
{Word/Halfword/Byte } 
{Long/Short} [Modified] 

Word Absolute {Indexed/Short} 
Word Absolute Short 
Offset 

And Clear Word {Indexed/Short} 
Bytes Short 


Store 

Load 

Store 

Load 

Load 

Store 


Branch Instructions 


(a) Unconditional 

Branch And Link {Displacement/Reg} 

Branch Vectored 
Branch External [and Link] 

Gateway 

(b) Conditional 

Add {Reg/Immed} And Branch if {True/False} 
Compare {Reg/Immed} And Branch if {True/False} 
Move {Reg/Immed} And Branch if {True/False} 
Branch On Bit {Variable/Constant} 

System Instructions 


(a) System Control 

System Mask {Set/Reset/Move to} 

Move {to/from} Control Register 
Move {to/from} Space Register 
Load Space ID 
Break 

Return From Interrupt 
Diagnose 

(b) Memory Management 

Insert TLB {Instruction/Data} {Address/Protection} 
Purge TLB {Instruction/Data} [Entry] 

Probe Access {Read/Write} {Reg/Immed} 

Load Physical Address 
Load Hash Address 

(c) Cache Management 

Flush {Instruction/Data} Cache [Entry] 

Purge Data Cache 
Sync 


Functional Instructions 

(a) Arithmetic 

Add {Reg/Immed} [with carry] [and Trap on 
{overflow/cond/overflow or cond}] 

Sub {Reg/Immed} [with borrow] [and Trap on 
{borrow/cond/borrow or cond}] 

Shift {One/Two/Three} And Add [and Trap on Overflow] 
Divide Step 

(b) Logical 

Or {Inclusive/Exclusive} 

And {True/Complement} 

Compare {Reg/Immed} And Clear 
Add Logical 

Shift {One/T\vo/Three} And Add Logical 

(c) Unit and Decimal 
Unit Xor 

Unit Add Complement [and Trap on Condition] 

Decimal Correct 
Intermediate Decimal Correct 

(d) Bit Manipulation 

Extract {Variable Pos/Constant Pos} {Signed/Unsigned} 
Deposit {Variable Pos/Constant Pos} {Reg/Immed} 

Zero and Deposit {Variable Pos/Constant Pos} {Reg/Immed} 
Shift Double {Variable Pos/Constant Pos} 

(e) Long Immediate 
Add Immediate Left 
Load Immediate Left 

Assist Instructions 

(a) Special Function Unit Interface 
Spop {Zero/One/Two/Three} 

(b) Coprocessor Interface 

Copr Load {Word/Doubleword} {Indexed/Short} 

Copr Store {Word/Doubleword} {Indexed/Short} 

Copr Operation 


Reg = register 
Immed = immediate 
Pos = position 
cond = condition 


is selected for a given instruction, while square brackets indicate an optional feature that can 


tion and hence maximize the probability 
that a constant can be represented as 
immediate data within the instruction. 
Usually, this would imply that the sign 
position, in its traditional encoding as the 
leftmost bit of an integer value, would 
occur in variable positions. Precision 
solved this problem by encoding the sign 
position of these variable-length immedi- 


ates as the rightmost bit, simplifying 
decoding and sign extension. 

Full-word immediates. Sometimes, even 
maximal-length immediates in an instruc¬ 
tion are not long enough, since a 32-bit 
immediate or displacement is needed. Pre¬ 
cision introduces 32-bit immediates in the 
instruction stream by using two fixed- 


length 32-bit instructions. For example, 
Load Immediate Left loads into a general 
register, GR/, a 21-bit immediate padded 
on the right with 11 zeros. A Load instruc¬ 
tion executed later, with this GR/ as the 
base register, supplies the low-order bits of 
the 32-bit displacement value. 

This method has the advantage that 
each instruction can still be a fixed-length 
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32-bit word, simplifying instruction fetch¬ 
ing and decoding. The alternative— 
variable-length instructions—requires 
either instruction alignment provisions 
with attendant memory wastage, or han¬ 
dling the complexity of a page-fault poten¬ 
tially occurring during an instruction 
fetch. 

A trade-off in the use of immediates 
arises in encoding space versus operation 
orthogonality, that is, the size of the value 
that can be represented by the immediate 
versus the other options that can be speci¬ 
fied in the fixed-length instruction. For 
instructions with a long immediate field, 
we chose to include only those instruction 
variants most frequently used rather than 
achieve full operation orthogonality with 
instructions where both operands come 
from registers. 

Memory reference instructions. Effec¬ 
tive address calculation for Precision load 
and store instructions uses the same exe¬ 
cution unit (Figure 2) as add instructions 
and is based on the same guideline of 
single-cycle execution. 

Static and dynamic displacements. All 
address calculations for load and store 
instructions are based on the base plus dis¬ 
placement, or base plus (shifted) index 
addressing modes, the most frequently 
used addressing modes. 9,10 Static dis¬ 
placements of 14 bits can be accomplished 
in one instruction, and 32-bit static dis¬ 
placements can be done with two instruc¬ 
tions using a long immediate instruction, 
as described earlier. Using an index regis¬ 
ter, 32-bit dynamic displacements are 
possible. 

Byte addressing. One reason Precision 
implements byte addressing rather than 
just word addressing is to allow the effi¬ 
cient movement of unaligned strings of 
bytes or characters, common in commer¬ 
cial computations. 

A unique Store_bytes instruction sim¬ 
plifies such moves by allowing storage of 
any sequence of one to four bytes starting 
at any byte location within a 32-bit word. 
This includes tribytes, defined as three 
consecutive bytes in a word. Storing of tri¬ 
bytes comes free with byte addressing. In 
other architectures, unaligned byte moves 
would have required loading and masking 
of the destination word. 

Address stride mechanisms. For 
indexed load instructions, the value in the 
index register can also be shifted by the 
data size to index bytes, halfwords, or 


words. Moreover, the instruction can 
specify address modification of the base 
register, with support of both pre- 
modification and postmodification. A 
load or store operation combined with 
address modification is another example 
of combining two operations in a single 
instruction word. 

A hardware-software trade-off resulted 
in the absence of indexed store instructions 
in the basic architecture. We chose to do 
this because achieving single-cycle execu¬ 
tion would require a register file with three 
read ports rather than two. Coprocessor 
indexed store instructions exist, however, 
since the data register being stored comes 
from the coprocessor rather than the basic 
processor. 

Another interesting encoding trade-off 
is that, in long-displacement load and store 
instructions, the timing of address modi¬ 
fication (pre or post) is encoded by the 
same bit that encodes the sign of the dis¬ 
placement (increment or decrement). This 
prevented cutting in half the range of the 
14-bit displacement while still allowing 
efficient accessing of stacks with the 
predecrement and postincrement options. 

Delayed load effect. Optimizing com¬ 
pilers for Precision processors try to insert 
one or more instructions after a load 
instruction to prevent interlocked pipeline 
cycles. However, Precision processors will 
interlock if an instruction following a load 
instruction uses a register with a pending 
load. This hardware-software trade-off 
incurs insignificant additional hardware 
complexity while preserving code compac¬ 
tion by not requiring the insertion of NOPs 
after load instructions, as in some other 
architectures without such interlocks. 3,11 
More significantly, the provision of hard¬ 
ware interlocks gives implementors the 
freedom to design different pipelines while 
guaranteeing object code compatibility. 

Branch instructions. Precision imple¬ 
ments delayed branching with some extra 
optimization features. In some architec¬ 
tures, 2,3,7,11 if a common instruction can¬ 
not be found, NOPs have to be inserted in 
the delay slot of a conditional branch, 
which can be executed for both paths of 
the branch. Precision achieves delayed 
branching with both static and dynamic 
code size reductions by enhancing the 
usage of the delay slot instruction follow¬ 
ing a conditional branch instruction. Con¬ 
ditional nullification is performed for 
backward branches only if the condition 
is false and for forward branches only if 


the condition is true. For example, by clos¬ 
ing loops with backward branches, com¬ 
pilers can always move the first instruction 
of the loop to the delay slot of the loop¬ 
closing backward branch, decreasing the 
loop size by one. By using forward condi¬ 
tional branches to rarely used code, soft¬ 
ware can again optimize the use of the 
delay slot instruction for the more fre¬ 
quently used fall-through path. If code is 
arranged so that backward branches are 
more likely to be taken than forward 
branches, then hardware can use the sign 
of the branch displacement as a static 
branch prediction bit. 

Simple Branch And Link instructions 
are used as procedure call primitives, with 
the return address saved in a general reg¬ 
ister. A base-relative branch using this 
general register is used for subroutine 
return. 

Functional instructions. Functional 
instructions execute a data transformation 
operation in a single pass through the ALU 
or SMU (see Figure 2). 

Arithmetic instructions. The Add and 
Subtract arithmetic instructions come with 
the widest range of options (see Table 1). 
The Add And Trap on condition option 
allows range checking, often required by 
high-level languages, to be accomplished 
with minimal instructions. 

Multiply and divide primitives. The 
Shift And Add instructions implement a 
simple integer multiply and accumulate 
function, using the standard ALU hard¬ 
ware (Figure 2) with a wider multiplexer on 
one port. Multiplication by small cons¬ 
tants can be accomplished in a few cycles, 
and multiplication by a variable can be 
done typically by breaking the multiplier 
into 4-bit pieces. 5 The Divide Step 
instruction implements a single-bit non¬ 
restoring division operation and can be 
used in a sequence to perform integer 
division. 

To implement full fixed-point integer 
multiply and divide in a single cycle would 
have required special hardware. We did 
not consider this cost-effective for a basic, 
general-purpose Precision processor 
because our studies of large collections of 
programs show that integer multiply and 
divide operations are rarely used, and mul¬ 
tiplication usually occurs with a constant 
known at compile time. 5,6 Hence, we 
included only simple multiply and divide 
primitives in the basic instruction set, with 
floating-point instructions and integer 
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Figure 5. Arbitrary bit field movement. 


multiply and divide instructions added as 
instruction-set extensions supported by 
optional hardware assists (described in the 
section on the Precision assists archi¬ 
tecture). 

Logical operations. The logical instruc¬ 
tions allow efficient implementation of 
arbitrary Boolean conditions. For exam¬ 
ple, the Compare And Clear instruction 
first assumes a Boolean value of false by 
storing zero in the target register. The 
negation of the desired Boolean condition 
is used to conditionally nullify the follow¬ 
ing instruction. This instruction, if not nul¬ 
lified by the Compare And Clear 
instruction, will set the target register to 
true. Other architectures usually require a 
branch instruction to implement the 
equivalent Boolean function. 

Unit and decimal primitives. Since a 
strategic goal for Precision Architecture is 
to support commercial applications, it 
must handle decimal operations in Cobol- 
like languages as well as alphanumeric 
code manipulation. The instruction set 
includes five instructions for parallel pro¬ 
cessing of small units (digits, bytes, and 
halfwords) within a word. 4,5 They are 
used for word-parallel string search and 
decimal arithmetic. The halfword units 
support the processing of 16-bit interna¬ 
tional character sets. 

Unlike floating-point arithmetic, these 
instructions do not require significant 
additional hardware. Hardware support 
consists only of condition logic on the 
carry bits of each 4-bit group of the ALU. 
Cobol applications—important on 
HP3000 machines—have been found to 
run many times faster on Precision 
machines than on the previous non- 
Precision-based HP3000 machines. 


Bit field manipulation. Although the 
main unit of transfer and operation is the 
32-bit word, often it is desirable to be able 
to manipulate arbitrary bit fields within a 
word or across a word boundary. Exam¬ 
ples include the efficient emulation of 
other instruction sets, bit-block transfers, 
unaligned byte moves, and field extraction 
from records. 

The shift-merge unit implements effi¬ 
cient bit-field manipulation instructions 
(see Table 1). For example, Extract takes 
an arbitrary-length field from any portion 
of a word and creates a result with this field 
right justified, with optional sign exten¬ 
sion. Deposit does the reverse operation, 
inserting a right-justified field into any 
portion of a target word, optionally clear¬ 
ing the rest of the target. Hence, in two 
instruction cycles Precision can perform 
an arbitrary bit field movement (see Fig¬ 
ure 5). Other architectures usually simulate 
these instructions by a sequence of shift¬ 
ing and masking. 


Extendibility and 
longevity features 

Beyond the simple execution model 
described above, Precision also includes 
features designed to give the architecture 
a potentially longer useful life by allowing 
growth and extendibility of the architec¬ 
ture. Below, I will describe some of these 
aspects: the virtual memory model, access 
protection, the assists architecture, the 
interrupt system, and the input-output sys¬ 
tem and multiple processor support. 

Virtual memory model. The Precision 
architects felt that the longevity of an 
architecture lies in the range of its address¬ 


ing capabilities rather than in the size of its 
words or the specific operations imple¬ 
mented. While processing 64-bit integers 
rather than 32-bit integers might increase 
accuracy, we did not consider the trade-off 
in the hardware required for 64-bit 
datapaths throughout the processor to be 
cost effective for general-purpose com¬ 
puters. 

However, computer usage has clearly 
tended towards the processing of larger 
programs and more data. Hence, the key 
to next-generation architectures is not as 
much the increase in data size from 32 to 
64 bits as the increase in addressing range. 
Precision provides a 64-bit virtual address 
range, which is four billion times more vir¬ 
tual storage than in current architectures 
with 32-bit virtual addresses. 7,9,11 

The large virtual address space allows 
virtual addresses to be defined globally 
across processes. This contrasts with 
architectures where the same address can 
be used for different objects by different 
processes. An advantage is that address 
translation information does not have to 
change on a process switch. Global virtual 
addressing allows interacting processes to 
accumulate a stable working set of address 
translations despite frequent process 
switching. 


Virtual address manipulation in the 
processor. Manipulating 64-bit virtual 
addresses efficiently with a 32-bit data 
path requires some ingenuity. Using the 
standard 32-bit ALU, effective address 
calculation in memory reference instruc¬ 
tions is performed for 32-bit quantities to 
determine the byte offset within a virtual 
space. The virtual space, selected from one 
of the eight space registers or the implicit 
program space register, is then con¬ 
catenated with the byte offset to give the 
full virtual address (see Figure 6a). Soft¬ 
ware conventions are commonly observed 
for the use of space registers. 4 

Different levels of the architecture are 
defined with respect to the size of the vir¬ 
tual space implemented: level-0 architec¬ 
ture with no space registers, level-1 
architecture with 16-bit space registers, 
and level-2 architecture with the full 32-bit 
space registers. This allows the virtual 
memory to be scaled down for a lower cost 
Precision processor by reducing the width 
of each entry in its translation look-aside 
buffer and attendant data paths. 

The architecture also incorporates a 
concept called “short pointers” to allow 
handling of 48-bit or 64-bit virtual 
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Figure 6. (a) Virtual memory organization and (b) short-pointer addressing. 


addresses with short 32-bit pointers (see 
Figure 6b). It allows, at a given time, data 
access to four distinct virtual spaces, each 
space being one gigabyte in size. Long- 
pointer addressing provides access to four 
billion virtual spaces, each space being 
four billion bytes in size (Figure 6a). Short- 
pointer addressing allows pointers to be 
the same size—32 bits—as the standard 
integer data type, a situation often 
assumed by existing high-level languages 
like C. It also allows efficient passing of 
pointers via the 32-bit general registers. 

Virtual space management in the 
memory-disk system. The virtual address 
is further partitioned into the space iden¬ 
tifier, the virtual page number (VPN), 


and the page offset. Each page has a fixed 
size of 2 kilobytes. The space identifier and 
the VPN are translated into a 21 -bit phys¬ 
ical page number (PPN), which is then 
used to access physical memory. If the 
physical page is not in memory, a page- 
fault occurs, and the missing page is 
brought in from the disk. 

Two software tables are used: a hash 
table to index into a page directory (Pdir) 
table, which contains one entry for each 
physical page in the main memory. Each 
entry in the Pdir is either empty or contains 
the VPN of the virtual page mapped to 
that physical page slot. This has the advan¬ 
tage of reducing the size of the page tables 
to correspond to the size of the physical 
memory, rather than to the size of the 


much larger virtual memory. Both the 
hash table and the page directory table per¬ 
manently reside in physical memory for 
performance reasons. 

To speed up the virtual to physical 
address translation process, a translation 
look-aside buffer (TLB) is defined as the 
processor’s interface to the virtual mem¬ 
ory system. This TLB acts as a cache for 
virtual to physical address translations. If 
an address translation is not in the TLB, 
a TLB miss occurs, handled either by a 
software interrupt routine or by a hard¬ 
wired sequence of operations. The archi¬ 
tecture defines memory management 
instructions for inserting, changing, 
querying, and deleting entries in the TLB 
(see Table 1). 
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Figure 7. Virtual address translation, protection checking, and cache accessing. 


Minimizing paging traffic. A dirty bit 
defined for every Pdir and TLB entry indi¬ 
cates if the page now differs from its disk 
image. This dirty bit is cleared to zero 
when the page is first brought in and when 
the page is written to disk, and remains 
clear as long as no writes to the page occur. 
The first time a program tries to write to 
that page, a dirty bit update trap occurs, 
which changes the dirty bit in both the Pdir 
and the TLB entry from zero to one. This 
allows the operating system to avoid writ¬ 
ing out unmodified pages to the disk. The 
increase in system performance is well 
worth the slight overhead in TLB and Pdir 
management. 

Address aliasing. A hardware-software 
optimization allows virtual cache index¬ 
ing, which facilitates single-cycle loads 
from virtual memory. It does this by not 
allowing software to do address aliasing or 
mapping of different virtual pages to the 
same physical page. While address alias¬ 
ing is of some use to software, it imposes 
significant performance degradations on 
hardware because it precludes the use of 
the virtual page as part of the index into the 
cache memory. 

For example, a virtual access could put 
data into the cache based on its index, and 


a later virtual access, using a different 
(aliased) address, would not find the data 
in the cache because the index was differ¬ 
ent in the virtual page portion. The second 
access would then go to memory, where it 
might get an inconsistent or stale copy of 
the data. 

By effectively disallowing address alias¬ 
ing, caches can use the virtual page num¬ 
ber as part of the index without causing the 
stale data problem. This allows the cache 
to be accessed in parallel with the virtual 
address translation being done by the TLB 
(see Figure 7), without restrictions on the 
size of the cache. If address aliasing were 
allowed, either virtual address translation 
and cache accessing would have to be seri¬ 
alized, or the cache size would have to be 
restricted to that of the page size multiplied 
by the cache set-associativity. 

Access protection. The architecture pro¬ 
vides hardware support for access protec¬ 
tion to be built into the storage unit and 
performed in the same cycle as virtual 
address translation and cache access (see 
Figure 7). 

Precision protection checking is defined 
at the page level, to control access to the 
page in three dimensions: the type of 
access allowed (read, write, or execute), 


the privilege level at which access is 
allowed, and the group of processes 
allowed access to the page. One reason for 
the choice of a 2-kilobyte page size rather 
than a larger one is so that access control 
can be defined at a finer granularity (use¬ 
ful in object-oriented environments, for 
example). 

Privilege levels. For access rights check¬ 
ing, the architecture defines four hierarchi¬ 
cal protection rings. The current privilege 
level of a process is checked against the 
privilege level for the read, write, or exe¬ 
cute access being made to that page by this 
process. 

Generalized supervisor/user transfers. 
This privilege-level mechanism allows a 
process to have different access rights over 
time without the overhead of changing 
TLB entries when access rights change or 
at process switch. Thus user programs 
(privilege level 3) can invoke the services 
of an operating system supervisor (privi¬ 
lege level 1) or kernel (privilege level 0) 
using an efficient procedure call rather 
than an interrupt or process switch. This 
can be done by a procedure call to a Gate¬ 
way instruction, which branches to the 
body of the more privileged routine. The 


COMPUTER 








































Gateway instruction can promote the priv¬ 
ilege level while saving the caller’s privilege 
level in the return address register so that 
it cannot be “forged” by the caller. On 
returning to the caller, a privilege- 
demoting branch instruction is used. 

Access identifiers. The currently execut¬ 
ing process can claim membership in up to 
four groups of pages simultaneously, each 
group having its own access identifier and 
write-disable bit, saved in four control 
registers. The access identifier allows each 
process sharing memory to access differ¬ 
ent domains in memory without the over¬ 
head of changing the TLB on process 
switch. Four access identifiers are 
provided to facilitate the controlled trans¬ 
fer of information between logical envi¬ 
ronments. These four access identifiers are 
checked against the protection identifier 
attached to the virtual page being accessed. 
A protection identifier of all zeros attached 
to a page allows public access to that page. 

When set, the write-disable bit disallows 
writing for all privilege levels to the pages 
protected by the associated access identi¬ 
fier. This allows, for example, a single 
writer and multiple readers for a group of 
processes accessing a common protected 
domain of pages. 

These protection features built into the 
architecture allow implementation of very 
secure, flexible environments. They might 
not be necessary for single-user or 
dedicated-controller environments, but 
they are necessary for efficient implemen¬ 
tation of secure multiuser systems. 

Assists architecture. One of the goals of 
Precision Architecture is to define a 
general-purpose, basic instruction set and 
allow future instruction set extensions. 
These future “assist” instructions could 
then be executed on optional hardware 
assists to speed up the processing of spe¬ 
cialized computations, such as floating¬ 
point or graphics. An assist instruction 
defines the architectural interface between 
the processor, memory, and any future 
assist in terms of data movement opera¬ 
tions, but we left specific functions per¬ 
formed by an assist for future definition. 

Software compatibility. While other 
architectures define backward software 
compatibility with a previous instruction 
set, 10 the Precision assists architecture 
defines forward software compatibility 
with future assist instruction sets. In addi¬ 
tion, software portability among Precision 


processors with different configurations of 
hardware assists is also achieved. These 
compatibility and portability goals are 
achieved by means of a transparent assist 
emulation trapping mechanism that auto¬ 
matically causes an interruption on detect¬ 
ing an assist instruction not supported by 
a hardware assist. This allows a software 
trap handler to perform the function 
required by the assist instruction, using the 
basic Precision instructions. Critical infor¬ 
mation needed for emulation is present in 
the interruption parameter registers, con¬ 
siderably speeding up the emulation 
routines. 

SFUs and coprocessors. The architec¬ 
ture recognizes two classes of assists: spe¬ 
cial function units (SFUs) and 
coprocessors. SFUs are viewed as very 
tightly coupled to the main processor 
buses, serving as alternate functional units 
to the ALU or SMU in the execution unit 
of a basic Precision processor. As such, an 
SFU receives its operands from the general 
registers and places its result into a general 
register, like a basic ALU instruction. A 
3-bit SFU identifier is attached to each 
SFU instruction, allowing up to eight 
SFUs simultaneously in a system. 

We view a coprocessor as a hardware 
assist coupled to the processor at the level 
of the data cache or memory. As such, it 
has its own set of coprocessor registers, 
loaded from or stored to memory using the 
same virtual address translation and pro¬ 
tection mechanism as the basic processor. 

Coprocessor load/store instructions are 
like processor load/store instructions, 
except that the target/source registers are 
coprocessor registers rather than the 
processor’s general registers. Coprocessor 
registers can be of a different size than 
processor registers; for example, the 
floating-point coprocessor registers are 64 
bits wide. 

Other than the coprocessor load/store 
instructions, there is only one other 
coprocessor instruction, where the opera¬ 
tions to be performed by the coprocessor 
can be defined as an instruction extension. 
As for SFUs, a 3-bit coprocessor identifier 
is attached to each coprocessor instruc¬ 
tion, allowing up to eight coprocessors or 
16 logically different assists in a Precision 
configuration. 

While an SFU provides execution-unit 
extendibility, a coprocessor also provides 
register-set extendibility. 

An example of an assist is the floating¬ 
point coprocessor (see Figure 8). The Pre¬ 
cision floating-point architecture allows 


highly pipelined implementations. It com¬ 
plies with the ANSI/IEEE 754-1985 
floating-point standard, although not all 
operations and exceptions need to be sup¬ 
ported by hardware, since an assists excep¬ 
tion trap can be used for software support 
of unimplemented features. 

For complex operations not frequent 
enough to justify the addition of assists 
hardware, a software call to a streamlined 
subroutine—called millicode —is used. 

Interrupt system. In Precision Architec¬ 
ture, the term “interruptions” includes all 
abnormal events like memory faults, pro¬ 
tection violations, computation excep¬ 
tions, hardware malfunction, power 
failure, timer interrupts, and external 
interrupts. Synchronous interruptions 
(those caused by instruction execution) are 
precise interruptions across all Precision 
processors, allowing predictability and the 
leverage of software interruption handlers. 
Asynchronous interruptions (external to 
the instruction stream, like machine 
checks, power failure, and external inter¬ 
rupts) provide a standardized way of 
reporting malfunctions, saving state, and 
giving rapid real-time response to external 
conditions and requests. 

Interruption registers. The interesting 
aspects of the Precision interrupt system 
are probably the ways in which the inter¬ 
ruption registers are used for fast context 
switching, expediting interruption process¬ 
ing, and implementing precise interrup¬ 
tions even with delayed branching. There 
are six control registers (Figure 3) used to 
save state, such as the processor status 
word (PSW) of the interrupted program, 
the instruction causing an interruption, the 
virtual space and offset for data memory 
reference instructions, and the virtual 
spaces and offsets of the first two instruc¬ 
tions processed upon returning from inter¬ 
ruption servicing. 

Fast context switch. Interruption servic¬ 
ing is implemented as a fast single-cycle 
context switch rather than a complete pro¬ 
cess swap. The information in the inter¬ 
ruption registers is usually continuously 
updated by a Precision processor during 
normal instruction processing so that, on 
detecting an interruption, the processor 
only has to save the current PSW in the 
interruption PSW register, clear the cur¬ 
rent PSW, and pass the control flow to a 
vectored location in a dynamically relocat- 
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able interruption vector table. Clearing the 
PSW has the effect of disabling other 
interruptions, freezing the interruption 
registers, and enabling real mode 
addressing. 

Eight control registers can be used as 
scratchpad registers for quick general- 
register saves under privileged software 
control. Upon completion of interruption 
processing, a Return From Interrupt 
instruction is executed, which restores the 
saved processor state and restarts execu¬ 
tion at the interrupted instruction. 

Precise interruptions with delayed 
branching. Delayed branching has been 
known to cause difficulties in interruption 
processing. Precision has easily solved this 
with the interruption instruction address 
(IIA) queue. The IIA queue consists of two 
instruction-return addresses, which are the 
first two instructions processed upon 
returning from the interruption. Interrup¬ 
tions caused by branch instructions are 
always taken after the branch instruction 
completes. 

The hardware automatically collects in 
the IIA queue the addresses of the delay 
slot instruction, followed by the target 
instruction of the branch (generally non¬ 
contiguous addresses). Since the IIA queue 
saves the return addresses of the time- 
sequential instructions following an inter¬ 
ruption, there is no restriction on a branch 
instruction occurring in the delay slot of 
another branch instruction. 


Flexible external interrupts. There are 
32 external interrupt classes, each of which 

_____can be individually masked by privileged 

Figure 8. Floating-point coprocessor, including (a) floating-point registers, software. When an external interrupt 

(b) floating-point data types, and (c) floating-point coprocessor instructions. occurs, its corresponding interrupt pend¬ 

ing bit is set in the external interrupt 
request register. If the corresponding mask 
bit in the external interrupt mask register 
is also set, an external interrupt is taken. 


X'00000000 

X'FOOOOOOO 

X'FFFFFFFF 
Figure 9. Physical address partitioning. 


Debugging and diagnostic hooks. The 
architecture provides debugging support 
traps to aid in software development. A 
Break instruction can be used to insert 
software checkpoints anywhere in the 
code, causing a break trap when executed. 
This instruction allows software encoding 
of bits within the instruction, which will be 
ignored by the hardware but interpreted by 
the software in the Break trap handler. 

Pages can also be tagged by two trap- 
enable bits that cause a trap whenever any 
reference is made to that page, or only 
whenever a store is made to that page. 
Traps can also be enabled whenever a 
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branch is taken, or whenever the privilege 
level of the running process is promoted or 
demoted. 

A recovery counter is defined to facili¬ 
tate the implementation of fault recovery 
in software rollback schemes and for 
single-step debugging. It can be enabled to 
cause an interrupt after the execution of a 
predetermined number of instructions. 

Precision Architecture also includes a 
Diagnostic instruction, whose only 
defined field is the 6-bit major opcode 
field. The rest of the instruction can be 
defined for implementation-specific oper¬ 
ations, like accessing pipeline registers or 
implementation-specific mode bits, not 
otherwise directly accessible by software. 
This instruction has proven very useful in 
boot-up, self-test, and diagnostic routines. 

I/O system and multiple processor sup¬ 
port. The architecture defines a memory- 
mapped input-output system, with I/O 
devices mapped to the top sixteenth of the 
four-gigabyte physical address space (see 
Figure 9). A Precision I/O module can be 
interrogated and controlled by software 
via load and store instructions. I/O 
addresses are not cached, and software 
maintains cache coherency for direct 
memory access by means of explicit cache 
control instructions. 

A simple semaphore operation. Load 
And Clear Word, resembles the test-and- 
set indivisible operation in earlier architec¬ 
tures. 10 Instructions for purging and 
flushing the translation look-aside buffers 
and caches allow software to maintain 
TLB and cache coherency when necessary. 

Bus standards have also been defined 
for hardware-managed TLB and cache 
coherency, in which case software sees 
only a single cache and a single TLB. The 
architecture does not constrain the type of 
asymmetric multiple processor support 
implemented by the total hardware- 
software system. 


Precision processor 
implementations 

While describing the range of Precision 
products is beyond the scope of this arti¬ 
cle, I will give some processor references 
and describe a typical pipeline. 

First-generation Precision processors 
have been implemented in a variety of 
technologies, including transistor- 
transistor logic, 12 n-type metal-oxide 
semiconductor, 13 complementary metal- 


Figure 10. Typical pipeline. 


oxide semiconductor, 14 and emitter- 
coupled logic (in a prototype), with a vari¬ 
ety of clock speeds, cache support, and 
TLB support, over a range of performance 
and cost. These processors are used in both 
the HP3000 series 900 business computer 
line and the HP9000 series 800 technical 
computer line. 

Figure 10 shows a typical pipeline for a 
Precision processor. 12 In the Fetch stage, 
the fetched instruction is decoded at the 
same time as the reading of the general 
registers. During the Execute stage, the 
operands are routed through the ALU or 
SMU, where a functional operation or 
address calculation occurs, and the condi¬ 
tion is also evaluated if necessary. At the 
end of the Execute stage, the result is 
stored in the general registers and also 
bypassed to the next Execute stage if 
necessary. 

There are no pipeline penalties for 
delayed branching, since the target address 
is calculated during the Execute stage at 
the same time the condition is evaluated 
for a conditional branch. This is done in 
time to fetch either the target instruction 
or the sequential instruction in the next 
cycle. Similarly, there are no pipeline 
penalties for load or store instructions, 
except when the register being loaded is 
used in the immediately following instruc¬ 
tion. This situation is minimized by Pre¬ 
cision optimizing compilers using code 
reordering. 

Attainment of the 
SPECTRUM goals 

In the spirit of architectural acro¬ 
nyms, 2 ' 3,7,9,11 I will take the liberty of 
defining a SPECTRUM architecture as 
one with the following goals: 

• Scalable implementations 

• Price-performance advantages 

• Extendible architecture 


• Commercial applications 

• Technical applications 

• Reusable components 

• Unconstrained lifetime 

• Multiple environments 

This makes Precision a SPECTRUM 
architecture, since the above goals include 
most of the major ones enunciated for its 
design. These goals are more similar to 
those addressed in the design of architec¬ 
tures like the IBM 360/370 architecture 10 
and the DEC VAX architecture 9 rather 
than to those of RISC microprocessor 
architectures. 2,3,7,11 

However, the Precision execution 
model shares many features common to 
these RISC architectures. 2,3,7,8,11 These 
include features like register-based execu¬ 
tion, simple load-store interface to mem¬ 
ory, delayed branching, simple addressing 
modes, fixed-length instructions, and 
three-register nondestructive functional 
instructions. Such architectural features 
can usually be implemented with simple, 
pipelined processor hardware, where 
single-cycle execution is achievable for 
most instructions. Since the hardware 
requirements are simple, these architec¬ 
tures are scalable in the sense that they can 
be implemented by low-cost hardware or 
by higher cost, higher performance proces¬ 
sors, which have very fast processor clock 
frequencies. A variety of process technol¬ 
ogies with different densities, speeds, and 
costs can be used. 

Since Precision instructions are executa¬ 
ble in a single cycle by simple hardware, we 
can say that the architecture has price- 
performance advantages—more instruc¬ 
tions can generally be executed in a given 
amount of time by less costly processors 
than in architectures with large, complex 
instruction sets. 9,10 However, simply 
executing more instructions in a given 
amount of time does not necessarily imply 
that more useful work is accomplished, 
especially if very little is accomplished in 















an average instruction. 2 ' 3 ' 7 " For this rea¬ 
son, Precision instructions try to combine 
frequent instruction pairs, like Compare 
and Branch, into one instruction. This 
saves both static code space and dynamic 
execution time, since one instruction 
replaces two and only one execution cycle 
is needed for both operations. 

In fact, all Precision functional instruc¬ 
tions have a built-in skip operation; mem¬ 
ory reference instructions can have base 
register address modification operations; 
and conditional branch instructions com¬ 
bine both the condition generating oper¬ 
ation and the branch operation in one 


instruction. In addition, the conditional 
branch nullification scheme and the con¬ 
ditional trapping scheme allow both static 
and dynamic code optimizations for loop¬ 
ing, jumps to error routines, and range 
checking. The use of maximal-length 
immediates also helps to reduce the num¬ 
ber of load instructions and the execution 
time involved. 

Note that, in computer systems with 
disks, tapes, graphics accelerators, and 
other I/O devices, the cost of the proces¬ 
sor subsystem is important, although not 
necessarily the dominating factor in sys¬ 
tem cost. Similarly, the performance of the 


processor subsystem is important, but not 
necessarily the dominating factor in sys¬ 
tem performance. 

The Precision assists architecture allows 
flexible instruction-set extendibility with¬ 
out sacrificing software compatibility. In 
fact, the built-in assists emulation trap 
allows software to be compatible among 
Precision systems with different configu¬ 
rations of hardware assists and even with 
future, as yet undefined, assists. The Diag¬ 
nose instruction also allows implementa¬ 
tion-specific instruction-set extensions. 
This is useful for implementing reliable 
and serviceable systems. 

The fact that Precision processors have 
been used in both the commercial HP3000 
and the technical HP9000 product lines 
attests to the general-purpose nature of the 
architecture. Decimal operations are sup¬ 
ported for Cobol applications, while effi¬ 
cient coprocessor integration contributes 
to high performance for floating-point 
applications. The most frequently used 
Precision instructions are quite different 
for Cobol, Fortran, or C applications. 

The Precision machine models have 
leveraged or reused key components 
like hardware VLSI processors, floating¬ 
point processors, cache and TLB con¬ 
trollers, and standard bus controllers. 
Both the HPUX (Unix) and MPE-XL 
operating systems can run, unmodified, on 
all Precision processor systems. By defin¬ 
ing not only user-visible architecture, but 
also system-visible architecture, Precision 
Architecture has defined not just an appli¬ 
cations binary interface, 7 but also a sys¬ 
tems binary interface. Naturally, when 
object code is compatible at the most 
privileged systems level, it is also com¬ 
patible at the least privileged user- 
applications level. Precision Architecture, 
together with Precision bus standards, has 
provided the potential for streamlining 
software, hardware, and input-output 
developments. 

The longevity of Precision Architecture 
is certainly unconstrained by its large 
64-bit virtual address space, since this is 
four billion times larger than current 32-bit 
virtual address architectures. 

The virtual memory structure and the 
built-in access protection features allow 
the implemention of multiple operating 
environments, since a large amount of 
addressability is provided, with provisions 
for various kinds of access control and 
protection for different domains of pages. 
The flexible bit-manipulation features 
enhance the emulation of older instruction 
sets, contributing to easy migration from 
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older HP machines. The external interrupt 
system allows environments requiring fast, 
real-time response to asynchronous 
events. The access protection features, 
machine checks, power-fail interrupt, and 
diagnostic features provide hooks for 
implementing secure, highly reliable, and 
serviceable systems. 


P recision Architecture has a simple 
execution model, where each 
instruction can be executed in a 
single cycle by a simple, scalable processor. 
This is enhanced by code compaction and 
execution time reduction features for the 
efficient processing of frequent operation 
sequences. The architecture provides a 
64-bit virtual address space to support 
growing user needs and flexible protection 
mechanisms to implement secure multi¬ 
user systems. Moreover, the assists archi¬ 
tecture provides forward compatibility 
with new instructions and register sets that 
can be added, with these instructions 
executed transparently by either hardware 
assists or software emulation. 

Precision Architecture provides a sys¬ 
tems binary interface for software com¬ 
patibility at both applications and systems 
levels. It forms the basis for the consolida¬ 
tion of hardware and software production. 
The architecture has been refined through 
extensive performance measurements and 
analysis and tested against various hard¬ 
ware implementations and software envi¬ 
ronments. It combines successful 
architectural ideas evolved from the past 
with several innovative features to support 
both current computing needs and future 
cooperative computing environments. □ 
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SPECIAL REPORT 


Software Pivotal 
to Strategic Defense 

Ware Myers, Contributing Editor 


S oftware clearly is the pivotal ele¬ 
ment in the success of the Strategic 
Defense System since it dominates 
the system functionally,” Charles A. 
Zraket, president and chief executive offi¬ 
cer of Mitre Corp., declared in a keynote 
address to the Second International Con¬ 
ference on Software for Strategic Systems 
in Huntsville, Alabama, October 26,1988. 

Zraket was a member of the Task Force 
on Military Software of the Defense 
Science Board, chaired by Frederick P. 
Brooks, that reviewed the Strategic 
Defense Initiative software in 1987. In 
1988 he chaired an advisory panel that 
extensively reviewed the Phase 1 system 
architecture and the battle manage¬ 
ment/command, control, and communi¬ 
cations subsystems for the Office of the 
Secretary of Defense. 

Developing this software will involve 
many organizations and thousands of peo¬ 
ple, Zraket noted. The enormous task fac¬ 
ing the Department of Defense is to forge 
these organizations and people into a team 
of unprecedented capability and coher¬ 
ence. To develop software of the reliabil¬ 
ity and trustworthiness necessary to the 
the success of the Strategic Defense System 
(SDS), this team must meet four 
challenges. 

First, the architecture of the overall SDS 
should be conceived with the needs of the 
software — highly distributed, high 
throughput, short response times, high 
reliability, maximum security — very 
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Making huge 
aggregations of 
weapons work 
together depends on 
well-conceived 
architecture and 
battle-scale simulation 
— and that takes 
increased investment 
in software 
environments. 


much in the forefront. System architec¬ 
ture, software requirements, algorithms, 
and software design need to be worked on 
together. 

Second, “because we cannot test SDS in 
a live wartime environment, battle simu¬ 
lations on a scale needed to represent a full 
battle realistically are required,” Zraket 
said. “These kinds of simulations have not 
been previously attempted, and it is there¬ 
fore critical to find ways of verifying 
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[their] accuracy if SDS is to be operation¬ 
ally trustworthy.” 

Third, to bring advanced software tech¬ 
nology to bear on the development, 
production, and test of this software, 
Zraket recommends “greatly increased 
R&D investment in software engineering 
tools, facilities, and training.” 

Fourth, more attention and money 
should be devoted to electronic informa¬ 
tion security. “The most critical software 
must be protected with encryption, 
authentication, and code validation with 
multilevel and compartmented controls,” 
Zraket said. “Very strict controls are 
needed on SDS operational algorithms 
and network control software.” 

Martin cites earlier systems. “Those 
who believe that SDS cannot be done 
should get out of the way of those who 
believe it can be done,” Edith Martin 
declared in her keynote to the conference’s 
opening session. Martin is vice president, 
technology, and assistant to the president, 
Boeing Electronics. She was deputy under¬ 
secretary of defense for research and 
advanced technology when DoD initiated 
the Stars software initiative in the early 
1980s. 

The concerns about SDS seem to focus 
on the testability of the software under 
conditions comparable to war, Martin 
continued. While this is a worthy concern, 
SDS is not the first large system that has 
not been tested in wartime. She cited the 
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Charles A. Zraket (left) of Mitre, Edith Martin of Boeing, and Maj. Gen. Eugene Fox of the Strategic Defense Initiative 
Office keynoted the Second International Conference on Software for Strategic Systems. The conference, held in Huntsville, 
Alabama, October 25-26, was chaired by Wayne Smith of General Research. Carl Davis of the University of Alabama in 
Huntsville served as program chair; Larry Tubbs of the US Army Strategic Defense Command was program cochair. 


Growth in size of operational software, 1950s to 1990s. 


System 

Operational Code 

Support Code 

Sage (1950s) 

100,000 

500,000 

Air traffic control (1960s) 

200,000 

1,000,000 

Safeguard (1970s) 

750,000 

2,000.000 

Norad and Spacecom* (1980s) 

2,000,000 

25,000,000 

SDS Phase 1 (1990s) 

2,000,000 

25,000,000 


’Includes Space Defense Operations, Intelligence Data Handling, Air Defense, Ballistic Mis¬ 
sile Warning, Communications Network Control, and Command and Control. 


example of the offensive deterrent missile 
force. 

Tests were conducted separately for the 
warheads on the ground, the delivery sys¬ 
tem, reentry, lethality of nuclear explo¬ 
sions on a hardened target, and other 
system elements. “These tests and simula¬ 
tions, taken together, constitute a high 
level of confidence that the system will 
work when activated in wartime,” she 
went on. “No one can guarantee that the 
system will not fail. . . yet it has served for 
30 years as the centerpiece of the nation’s 
security.” 

SDIO reduces costs. To reduce the costs 
of the system, the Strategic Defense Initia¬ 
tive Office has to find innovative ways to 
develop the software, Maj. Gen. Eugene 
Fox, acting deputy director of SDIO, said 
at the conference banquet. He was filling 
in for Lt. Gen. James A. Abrahamson, 
SDIO director, who was in Europe. 

Fox outlined how SDIO’s top staff had 
spent last summer rethinking Phase 1 in 
order to get its cost down from $ 115 billion 
to $69 billion, the level that Secretary of 
Defense Frank C. Carlucci considered to 
be affordable under current fiscal con¬ 
straints. As a result of this redirection, Fox 
said that Secretary Carlucci, Undersecre¬ 
tary for Acquisition Robert B. Costello, 
the Joint Chiefs of Staff, SDIO, and other 
elements of DoD are as one in backing the 
program and its budget. 

To provide a focus for improving soft¬ 


ware productivity, SDIO plans to establish 
a Center of Excellence for software at the 
National Test Facility, Colorado Springs, 
Fox said. 


Getting the errors down 

“An instrument does not become a 
weapon until it can be handled reliably by 
a private soldier or at least a senior lieu¬ 
tenant,” says a colonel in the USSR 
Armed Forces in Tom Clancy’s thriller, 
The Cardinal of the Kremlin. “If we are to 
bring this site to operational status, it 
would be well to know that the damn fool 
thing will work when we want it to.” 

It may take more than a few privates 
and lieutenants to operate SDS, but that 
is the basic problem, said Mack Alford, 
chief scientist of Ascent Logic, speaking at 
the panel on software technology issues. 


The basic solution, of course, is to get the 
errors down. 

Zraket sets goal. “Improved semantic 
analysis and formal testing should 
decrease error rates in delivered software 
by a factor of 10, from 1-3 errors per 1,000 
instructions to 0.1-0.3 errors per 1,000 
instructions,” Zraket projected. As error 
rates have come down, however, the size 
of operational software has grown by a 
multiple of two or three each decade (see 
table). 

“It is likely that Phase 1 deployed oper¬ 
ational code will total over two million 
[lines of code], ’ ’ Zraket estimated, “ but I 
would guess not much more, and its total 
code, including National Test Bed simula¬ 
tion and software engineering environ¬ 
ments, maybe over 25 million, perhaps up 
to 30 to 40 million.” 

At typical current error rates (1-3 per 
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1,000 lines of code) the operational code 
would have 2,000 to 6,000 errors; the sup¬ 
port code, 25,000 to 75,000 errors. If 
Zraket’s order-of-magnitude reduction in 
error rates can be achieved, the opera¬ 
tional code would be down to 200 to 600 
errors; the support code, 2,500 to 7,500 
errors. 

In 1985 Fred Brooks applied the famous 
question, “How good is good enough?” 


to the SDS software. In terms of the 
protective-shield ideal, even the reduced 
number of errors is not good enough. In 
terms of the Phase 1 goal of intercepting 
one-third to one-half of the incoming mis¬ 
siles, the reduced number of errors is prob¬ 
ably good enough. 

Existence proofs. The Space Shuttle 
software record provides an existence 


proof that very large systems can reach 
near-zero significant defects. The 500,000 
lines of source code on board the 1985 
shuttle flights (before the Challenger dis¬ 
aster) achieved a low of 0.11 errors per 
1,000 instructions after release, according 
to Barbara Kolkhorst of IBM Federal Sys¬ 
tems Division, Houston, speaking at the 
International Conference on Testing 
Computer Software last June. 


SDI software: 19834988 


March 1983. “I call upon the scientific community, who gave 
us nuclear weapons, to turn their great talents to the cause of 
mankind and world peace; to give us the means of rendering 
these nuclear weapons impotent and obsolete,” President 
Reagan said in a televised speech. 

October 1983. “Developing hardware will not be as difficult 
as developing appropriate software,” according to the Defen¬ 
sive Technologies Study Team, chaired by James C. Fletcher. 
“Very large (order of 10 million lines of code) software that 
operates reliably, safely, and predictably will have to be 
deployed. It must be maintenance-free for 10 years.” 

June 1985. David Lorge Parnas resigned from the Strategic 
Defense Initiative Organization’s Panel on Computing in Sup¬ 
port of Battle Management, saying, “Because of the extreme 
demands on the system and our inability to test it [under oper¬ 
ational conditions], we will never be able to believe, with any 
confidence, that we have succeeded [in achieving a trustwor¬ 
thy system].” 

August 1985. “It is much too soon for gloom. I see no reason 
why... any competent, experienced software manager... 
could not undertake to build such a system,” Frederick P. 
Brooks, responded to Parnas during a panel discussion at the 
Eighth International Conference on Software Engineering. 

December 1985. The Panel on Computing in Support of Bat¬ 
tle Management concluded that “computing resources and 
battle management software for a strategic defense system 
are within the capabilities of the hardware and software tech¬ 
nologies that could be developed within the next several 
years.” It selected a dozen research areas that promise to pro¬ 
vide methods that will improve productivity and quality. The 
panel anticipated the great complexity of the battle manage¬ 
ment software and recommended an approach to the system 
architecture that would make it possible to build a trustworthy 
system. 

July 1987. The Defense Science Board Task Force on Mili¬ 
tary Software, chaired by Frederick P. Brooks, found that SDIO 
has “a monumental software problem that must be solved to 
attain the goals of the initiative.” The problems are the magni¬ 
tude of the software and the complexity of controlling the 
interactions of many components with rapid communications 
and response times. The task force urged that SDIO “focus a 
critical mass of software research effort” on SDI-unique prob¬ 
lems, not general software technology problems, already 
being studied by other organizations. It recommended “evolu¬ 


tionary acquisition, including simulation and prototyping, to 
reduce risk.” 

August 1987. The Congressional Office of Technology 
Assessment: "The nature of software and experience with 
large, complex software systems indicate that there may 
always be irresolvable questions about how dependable BMD 
software would be and about the confidence the United States 
could place in dependability estimates. Existing large soft¬ 
ware systems, such as the long-distance telephone system, 
have become highly dependable only after extensive opera¬ 
tional use and modification. 

“In OTA’s judgment, there would be a significant probability 
(that is, one large enough to take seriously) that the first (and 
presumably only) time the BMD system were used in a real 
war, it would suffer catastrophic failure. The complexity of 
BMD software, the changing nature of system requirements, 
and the novelty of the technology to be controlled raise the 
possibility that the system may not even be able to pass the 
more realistic of the peacetime tests that could be devised for 
it. The relatively slow rate of improvement in software 
engineering technology makes it appear unlikely to OTA that 
this situation will be substantially alleviated in the foreseea¬ 
ble future.” 

October 4,1988. Secretary of Defense Frank C. Carlucci 
approved a reduced version of Phase 1 (kinetic-kill weapons) 
worked out by SDIO over the previous six months. The pro¬ 
posed cost was cut from $115 billion to $69 billion. Phase 1, to 
be deployed in the late 1990s, is not intended to provide a leak- 
proof defense of the entire United States. It is planned to inter¬ 
cept enough missiles (the exact percentage is classified, but 
it is believed to be about one-third to one-half) to discourage a 
first strike. The President’s protective shield remains the ulti¬ 
mate goal for Phase 2 (laser weapons) and Phase 3 (particle- 
beam weapons) in the early decades of the next century. 

October 6,1988. Several more years of research are needed 
“to demonstrate that these technologies are mature enough 
to be weaponized, that this system will perform as advertised 
and as expected, and that the costs ... are reasonable and 
absorbable,” Gen. Robert T. Herres, vice chairman of the Joint 
Chiefs of Staff, testified before a joint hearing of the House 
and Senate Armed Services Committees. 

October 25-26,1988. The Second International Conference 
on Software for Strategic Systems in Huntsville, Alabama, 
provided an opportunity for participants in strategic defense 
research and development to compare notes on progress dur- 
ing the 18 months since the first conference. _ 
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The Discovery mission last September 
returned to ground after four days in orbit 
with only one new software defect detected 
in the three million lines of mission-control 
ground software, John B. Munson, vice 
president and general manager of Unisys 
Houston Operations, reported to the pres¬ 
ent conference. The defect, which was not 
critical, was traced to an error in stating a 
requirement. In addition to this newly 
detected problem, the shuttle flew with 
other known but unimportant ground 
software errors, correction of which had 
been deferred to the next release. This rec¬ 
ord should be considered in terms of the 
substantial amount of work that had been 
done on the ground software since the 
Challenger disaster. For example, some 
850 software people implemented 3,800 
requirements changes. 

Of course, both the on-board and the 
ground software is the end result of some 
15 years of development and test and 22 or 
23 missions. It should also be noted that 
there has been operational use of the soft¬ 
ware in the shuttle program that is not pos¬ 
sible in the SDS case. 

Both Kolkhorst and Munson stressed 
that no magic was employed in achieving 
these results. In general, both organiza¬ 
tions just applied good software engineer¬ 
ing practices to a high degree. 

“Software development is very hard, 
complex, tedious work,” Munson 
insisted. “It revolves around one thing — 
engineering discipline.” 

The record of the Safeguard ballistic 
missile defense system implies the same 
philosophy. It was developed in six years 
and operated for 10 months in the 
mid-1970s before languages like Ada, inte¬ 
grated software engineering environ¬ 
ments, and high-powered individual 
workstations were available. Bell Labora¬ 
tories was the software contractor. During 
Safeguard’s brief operational period, 258 
flight and intercept tests were conducted, 
Edith Martin said. 

“The last 21 flights worked perfectly,” 
she reported. “Comprehensive tests at 
Grand Forks, North Dakota, showed the 
availability of the system to be 99.3 percent 
over the whole 10-month period.” 


Software engineering 
environments 

Strategic systems are typically very large 
(more than one million lines of code). They 
operate in real time, the performance 


requirements are severe, their software is 
distributed over geographically dispersed 
networks of often different computers, 
and many processes take place concur¬ 
rently. 

“Developing [these] systems continues 
to be a constant fight with complexity,” 
Jerome Heitner of the General Electric 
Strategic Systems Dept, observed. “Man¬ 
ual methods are inadequate . . . We must 
significantly automate the way we develop 
requirements.” 

“Complex system development is not 
adequately supported with tools sets devel¬ 
oped to support a less complex class of 
problems,” a TRW publication dis¬ 
tributed at the conference stated. 

One part of the solution to this problem 
is software engineering environments espe¬ 
cially directed to this class of systems. One 
environment is being developed by TRW 
for the Army Strategic Systems Command 
with a spin-off being marketed by a com¬ 
mercial company. Another approach is 
being put together by Lockheed Missiles 
and Space for the space station. MCC is 
working with its shareholders on a dis¬ 
tributed computing project. 

DCDS and RDD. The roots of the 
TRW-Army environment go back as far as 
1968. The first Army contract was let in 
1974. The product, called the Distributed 
Computing Design System, now embod¬ 
ies 240,000 lines of code and has cost about 
$20 million. It is used at 18 beta sites, 25 
corporations, and many universities. In 
October 1987 the Defense Acquisition 
Board advised its use on SDI contracts. 

‘ ‘Yet the DoD versions of DCDS are not 
commercial products,” Heitner con¬ 
tended. “[They] are generally marred by 
a poor user interface. ” 

TRW said that the present version is 
“expert friendly,” but it is in the process 
of making it more “user friendly. ” A com¬ 
mercial product from Ascent Logic, called 
the Requirements Driven Development 
and based on DCDS, was demonstrated 
publicly for the first time at the confer¬ 
ence. It contains improvements that 
enhance the user acceptability of DCDS. 

“The tools in RDD are now opera¬ 
tional,” Mack Alford told the software 
technology panel. Alford spent 15 years on 
DCDS at the Strategic Defense Command 
and was one of the founders of Ascent 
Logic. “RDD is running on Sun, Apollo, 
and Macintosh II,” he said. 

These tools were specifically designed to 
support what systems engineers do — 
decompose, allocate, and interface, 


Alford said. The behavior model in DCDS 
and the implementation of it in RDD 
explicitly define concurrency — both con¬ 
current actions going on and concurrent 
actions per object when hundreds of 
objects are simultaneously going through 
detect, track, verify, and so on. The tools 
permit users to review the design decisions 
that have been made. When a change is 
made, it ripples through the entire data¬ 
base, enabling the user to see the things 
that should change. 

RDD deals with the problem of many 
people working together by assigning 
ownership to each individual element. “If 
you own it, you can change it,” Alford 
said. “If you don’t, you can’t.” 

GE Strategic Systems is using RDD to 
manage requirements development during 
the SDI demonstration and validation 
phase, Heitner said. The Automated 
Requirements Manager, as GE calls it, 
methodically forces early recognition of 
requirements issues and rigorously tracks 
their resolution. It provides a uniform 
framework encompassing originating 
documents, critical issues, design deci¬ 
sions, functions, design structures 
integrating data and control flows, con¬ 
currency, performance, interfaces, and 
physical allocations to components. 

The requirements manager contains a 
rule base derived from the systems- 
engineering knowledge accumulated for 
DCDS. It enables system engineers to 
check system behavior by means of dia¬ 
logues with the requirements manager. 

With the Automated Requirements 
Manager, GE has developed for SDIO an 
early requirements framework sufficient 
to drive end-to-end architecture simula¬ 
tions, Heitner said. “Initial experiments to 
force requirements to drive simulations 
have been performed.” 

NASA SSE. NASA has laid out a six- 
year program expected to cost about a 
quarter of a billion dollars to develop the 
space station software support environ¬ 
ment (SSE). The program is now in its sec¬ 
ond year with Lockheed as the contractor, 
said Pat Rich, manager of the project, at 
the software technology issues panel. 

The SSE Development Facility at John¬ 
son Space Center, Houston, is the creator 
and maintainer of all versions of the envi¬ 
ronment. “One common misconception is 
that SSE is one single environment defini¬ 
tion,” Rich said. “It is the definition of a 
set of technologies that go into building 
various instances of that environment tai¬ 
lored to specific user requirements.” 
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SSE is more than a development tool 
set. In addition to hardware, it contains 
elements such as management support and 
the reusable software library. The project 
intends to adhere to standards so that over 
the long run it can integrate tools that 
become commercially available. 

“This environment is mandated for the 
work-package contractors,” Rich said. 
“It is not mandated for the international 
partners, although they are being 
encouraged to use it.” 

MCC. “Our shareholders want dis¬ 
tributed systems because they are 
interested in the increased performance 
that concurrency provides,” Michael 
Evangelist of the Software Technology 
Program, Microelectronics and Computer 
Technology Corp., said. Evangelist’s proj¬ 
ect has developed a new language for dis¬ 
tributed systems, called Raddle, and a 
visual environment, called Verdi, for 
building, executing, and analyzing Raddle 
designs. 

Three shareholders are using the 
research prototypes of Raddle and Verdi, 
but they haven’t built large-scale designs 
yet. 


Simulation 

“The major algorithms for SDS involve 
the functions of surveillance, tracking, dis¬ 
crimination, weapons assignment, 
weapons control and guidance, network 
routing and control, security-access con¬ 
trol, and system fault-tolerance and fail¬ 
safe operations,” Zraket explained. “The 
designs of these algorithms are crucially 
dependent on threat missiles and possible 
attack modes, and performance data on 
SDS sensors, weapons, and communica¬ 
tions. It is important that algorithms be 
tested on an end-to-end basis and that this 
testing be done using actual code rather 
than emulating their desired behavior, as 
is currently done by most simulators. 

“There are two separate but related 
ideas here. The first idea involves ‘chain¬ 
ing,’ that is, the driving of an algorithm 
by its upstream input algorithms, ’ ’ Zraket 
continued. “In effect, we have a chain 
that we must trace through from threat to 
sensor detection and track association to 
track correlation to track prediction to 
track discrimination to weapons assign¬ 
ment, guidance updates, and finally kill 
assessments. 

“Since we cannot specify at this time 


exactly what the performance of each of 
our algorithms will be, we must find out 
how well things work by actually connect¬ 
ing together coded algorithms of engineer¬ 
ing fidelity,” he went on. “For example, 
the quality of predicted positions of tracks 
will depend critically on the details of the 
estimation of the present position of the 
target. Also, the quality of interceptor gui¬ 
dance and the amount of interceptor divert 
velocity needed will depend directly on the 
details of track prediction.” 

That leads to the need for a credible 
simulation capability. SDIO has recog¬ 
nized this need and in January 1988 
initiated the National Test Bed. Here, two 
capabilities must be developed, in Zraket’s 
view: 

(1) a model-evaluation process to estab¬ 
lish the credibility of models and simula¬ 
tions, and 

(2) an experiment-design process to fos¬ 
ter systematic and informative 
experiments. 

A systems-oriented software engineer¬ 
ing environment is needed to integrate 
both development and evaluation of the 
end-to-end system with both actual and 
simulated components. 

“To achieve this capability, a strong 
research program is needed, since this con¬ 
cept is quite immature at this time,” 
Zraket said. “Most of the current SDS 
simulations lack fidelity, high resolution, 
and also the actual code for SDS 
algorithms and battle management/com¬ 
mand, control, and communications. 
Sophisticated software engineering is 
needed to support geographically dis¬ 
tributed simulation and experimental 
activities. These activities will need to inte¬ 
grate high-fidelity engineering simula¬ 
tions, operator/equipment/software-in- 
the-Ioop experiments, and background 
phenomenology/threat simulations. ’’ 


Getting productivity up 

“The keys to improved productivity in 
software development and production — 
up to a factor of 10 in the next decade — 
will be in better software engineering envi¬ 
ronments, use of Ada and very high level 
languages that are applications oriented 
(the so-called fourth-generation lan¬ 
guages), high-performance hardware and 
workstations, and techniques such as 
object-oriented programming,” Zraket 
said. 


Recently Mitre surveyed well over 100 
software-intensive systems that it had 
supervised during the past five years for 
the Air Force Electronic Systems Division. 
The most critical problems, especially in 
the sensor and communications programs, 
were the lack of skilled people, inadequate 
top management awareness and experi¬ 
ence, and inadequate capital investment in 
software engineering environments and 
other tools. 

“The people and organizations that 
have in-depth experience in sensor and 
communications hardware lack software 
knowledge and experience,” Zraket said. 
“The reverse is also true and has led to 
many economic and performance disasters 
in producing reliable software in programs 
where the software was a small part of the 
total system cost but dominated the system 
functionally and in determining its oper¬ 
ational schedule.” 

Software investment. “Most companies 
have made major investments in their 
hardware technologies; few have invested 
in tools and training for software develop¬ 
ment,” Zraket went on. “This is the main 
reason why I believe the state of the prac¬ 
tice is 10 years behind the state of the art. 

“My one clear recommendation today 
to SDIO, the Army, Air Force, Navy, and 
Office of the Secretary of Defense is that 
greatly increased R&D investment is 
needed in software engineering tools, facil¬ 
ities, and training,” he continued. “Also, 
procurement incentives must be designed 
and used by DoD that will encourage com¬ 
panies to invest in these areas.” 

DoD expenditures for software, includ¬ 
ing maintenance, are estimated to be about 
$30 billion per year. The canonical for¬ 
mula calls for investing about 10 percent, 
or $3 billion per year. ‘ ‘Today it is signifi¬ 
cantly less than one percent,” Zraket said. 
Investment in the next decade must be in 
the few billions of dollars per year, not the 
few tens of millions now being spent. 

“The commercial market will not make 
up the difference in meeting DoD’s 
needs,” he added. “Neither will lots of 
smart people who are given small amounts 
of research funds.” 


Investment per engineer. Organizations 
have been accustomed to providing soft¬ 
ware engineers with a desk, bookcase, and 
filing cabinet, often in a concentration- 
defeating bull pen. Software organizations 
must raise their sights above that level, but 
perhaps not as high as some believe, if the 
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experience of a Rational special-projects 

I representative can be taken as a guide. 
Rational produces a software engineering 
environment that runs on its own 
computer. 

Kevin J. Haar, in an interview at the 
[ conference, estimated that costs for a 
Rational installation run between $20,000 
and $28,000 per engineer. The lower end 
of the scale is experienced by large compa- 
[ nies spreading the cost over many people. 

The higher end applies to smaller compa¬ 
nies with fewer people to absorb the cost. 
In some situations junior people don’t 
> need the full power of the Rational work- 
f station and can get along with PC-level 
| equipment, further reducing the average 

In Haar’s personal experience, the resis- 
[ tance point to investing the money has 

I usually been in contractor management, 

i He has found government contracting 

I officers willing to cooperate in encourag- 

| ing capital investment to improve software 

I productivity. 

Reducing costs. Analyzing a cost- 
I estimating model, Barry Boehm, chief 

I scientist of TRW’s Defense Systems 

| Group, identified three fundamental 

I approaches to improving productivity: 

reduce the cost-driver multipliers, reduce 
I the amount of code, and reduce the scal- 
[ ing factor that relates the number of 
r instructions to the number of man-months 
| or dollars. The model looks like this: 

| Effort = Constant *Size Slgma *MuItipliers 

The multipliers have to do with such fac- 
I tors as ‘ ‘how well you are supporting the 
I job with tools, how much you avoid over¬ 
constraining the software to live within 
t limited hardware, picking better or more 
experienced people, and things like that, ’ ’ 
Boehm said. His data show that picking 
the right people has the most influence on , 
[ productivity. The next two most important 
I multipliers have to do with reliability and 
I complexity. 

“Ada is a richer, more complex lan- 
1 guage [than its predecessors],” Boehm 
[ observed, “so people who don’t know it 
| hurt you more; people who do know it help 
I you more. Based on what we can come up 
l with so far, it looks like Ada can reduce the 
added cost of building highly complex, 

| highly reliable software. ” 

As more advanced environments have 
[ come along, the productivity benefits 
resulting from things like tools or reduced 


turnaround time are becoming bigger than 
they were in the late 1970s. Doing better on 
these and other factors reduces the numer¬ 
ical value of the multipliers and, hence, the 
amount of effort, or dollars. 

The second option, reducing the size, 
can be accomplished by reusing code, 
using commercial off-the-shelf software, 
or using very high level languages, which 
implement the same amount of function¬ 
ality in fewer instructions. 

“The only places that we really experi¬ 
ence spectacular improvements in produc¬ 
tivity are in narrow-domain areas where 
we have been able to master the domain 
sufficiently to be able to build special- 
purpose languages or systems to create 
that kind of software,” Boehm said. 
“Even in the sixties we had special- 
purpose aids to do things like rocket trajec¬ 
tories. A major future opportunity is to 
build these aids for some of the aerospace 
applications. 

“For the foreseeable future we will 
probably have to plug along doing better 
and better things in general-purpose lan¬ 
guages, but there is still the opportunity to 
get factors of five or six improvements in 
productivity, even in the general case.” 

The third element in the equation is the 
exponent, sigma. In the Cocomo model 
this exponent was about 1.2. For large 
aerospace applications this value amounts 
to a fairly large diseconomy of scale. When 
you double the size of the software, you 
multiply the cost by 2 1 ' 2 , which is 2.3. In 
other words, the cost is doubled, plus a 30 
percent penalty for size. 

This penalty results from a number of 
inefficiency influences. “You bring a big¬ 
ger team on board, ’ ’ Boehm pointed out. 
“The people on the team spend more time 
talking to each other. There is more learn¬ 
ing curve effect as you bring in people who 
don’t know what you are building. There 
is a lot of thrashing in the process any time 
there is a proposed change or things that 
haven’t been determined that people are 
trying to determine. Any time you do have 
a change, there are ripple effects that are 
more inefficient on big projects than on 
small projects.” 

Boehm posed two questions: Is there 
some way of stabilizing the process or 
reducing communications overhead that 
will reduce these ripple effects? Is there 
some way to reduce sigma? “The ones we 
have come up with are rigorous design 
interfaces, early risk elimination, and 
requirements statements,” he answered. 

The process model that is all too fre¬ 
quent in building large government sys¬ 


tems starts with a success-oriented 
mentality that tells itself, “Since we have 
convinced ourselves that we know exactly 
how to build this thing, we will schedule 
preliminary design review in 90 days and 
we will produce 52 contract data require¬ 
ments items.” 

What this mental set does is get at least 
52 people on the job thrashing around try¬ 
ing to write these documents, Boehm went 
on. This course does not produce a valid 
design. So, the theory goes, bring another 
hundred people on board. Have them 
thrash around, trying to understand the 
design. 

“Even if you did not have a good inter¬ 
face here, once you have some code, you 
have a long integration and test phase still 
ahead,” Boehm said. 

This “thrashing around” model is obvi¬ 
ously counterproductive. Therefore, 
Boehm outlined a better approach. 

Ada process model. Efforts to reduce 
risk, minimize requirements changes, and 
specify interfaces more precisely, along 
with the use of the software engineering 
methods encouraged by the Ada language, 
amount to a new way of engineering very 
large systems. Boehm called this way the 
Ada process model and characterized it 
with a set of guidelines: 

• Use a set of risk management plans to 
drive the process, using incremental devel¬ 
opment to stabilize the process. 

• Try to get the uncertainties out of the 
requirements, partly by prototyping. 

• Use a small top team for the archi¬ 
tecture. 

• Provide strong tool support for the 
early phases. 

• Don’t force yourself into preliminary 
design review in 90 days. 

• Don’t force yourself into having to 
build 52 documents in 90 days. 

• Don’t overload yourself with a huge 
number of people because you have a job 
number to charge to. 

• Don’t use document milestones to 
drive the project organization. 

• Don’t force yourself into having sep¬ 
arate requirements and design teams. You 
have to integrate them. 

• Don’t force every development into 
the same sequence. 

• Don’t wait around passively for some¬ 
one to provide you with definitive 
requirements. 

“Software people have to get involved 
in the systems engineering part of things, ’ ’ 
Boehm concluded. “That, I think, is the 
biggest leverage item of all.”□ 
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Breaking into computers is a crime, pure and simple 

Edward A. Parrish, Jr.. Past President, IEEE Computer Society 


During the last few years, much has 
been written to publicize the feats of 
computer hackers. There was, for 
example, the popular movie War Games, 
about a teen-ager who, using his home 
computer, was able to tap into a military 
computer network and play games with 
the heart of the system. The games got 
out of control when he chose to play 
“thermonuclear war.” The teen-ager, who 
was depicted with innocent motives, 
eventually played a crucial role in solving 
the problem and averting a real nuclear 
exchange, in the process emerging as 
hero. A real-life example in early 
November involved a so-called computer 
virus (a self-replicating program spread 
over computer networks and other media 
as a prank or act of vandalism), which 
nearly paralyzed 6,000 military and 
academic computers. 

Unfortunately, perhaps because the 
effect of such “pranks” seems remote to 
most people, it is tempting to view the 
hacker as something of a folk hero — a 
lone individual who, armed with only his 
own ingenuity, is able to thwart the 
system. Not enough attention is paid to 
the real damage that such people can do. 
But just consider the consequences of a 
similar “prank” perpetrated on our air- 
traffic control system, or a regional 
power-control grid, or the banking 
system, or a hospital information system. 
The incident in which an electronic 
intruder broke into an unclassified 
Pentagon computer network, altering or 
destroying some files, caused potentially 
serious damage. 

We do not really know the full effect 
of the November virus incident that 
brought many computers on the Cornell- 
Stanford network to a halt, but credible 


published estimates of the cost in man¬ 
hours and computer time have been in the 
millions of dollars. The vast majority of 
professional computer scientists and 
engineers who design, develop, and use 
these sophisticated networks are dis¬ 
mayed by this total disregard of ethical 
practice and forfeiture of professional 
integrity. 

Ironically, these hackers are perhaps 
driven by the same need to explore, to 
test technical limits that motivates 
computer professionals; they decompose 
problems, develop an understanding of 
them and then overcome them. But 
apparently not all hackers recognize the 
difference between penetrating the 
technical secrets of their own computer 
and penetrating a network of computers 
that belong to others. And therein lies a 
key distinction between a computer 
professional and somebody who merely 
knows a lot about computers. 

Clearly a technical degree is no 
guarantee of ethical behavior. And 
hackers are not the only ones who abuse 
the power inherent in their knowledge. 
What, then, can we do? 

For one thing, we — the public at large 
— can raise our own consciousness: 
Specifically, when someone tampers with 
someone else’s data or programs, 
however clever the method, we all need 
to recognize that such an act is at best 
irresponsible and very likely criminal. 
That the offender feels remorse, or that 
the virus had unintended consequences, 
does not change the essential lawlessness 
of the act, which is in effect breaking- 
and-entering. And asserting that the act 
had a salutary outcome, since it might 
lead to stronger safeguards, has no more 
validity than if the same argument were 


advanced in defense of any crime. If after 
experiencing a burglary I purchase a 
burglar alarm for my house, does that 
excuse the burglar? Of course not. Any 
such act should be vigorously prosecuted. 

On another front, professional societies 
such as the IEEE Computer Society can 
take steps to expel, suspend, or censure as 
appropriate any member found guilty of 
such conduct. Finally, accrediting 
agencies, such as the Computing Sciences 
Accreditation Board and the Accredita¬ 
tion Board for Engineering and Technol¬ 
ogy, should more vigorously pursue their 
standards, which provide for appropriate 
coverage of ethical and professional 
conduct in university computer science 
and computer engineering curriculums. 

We are well into the information age, a 
time when the computer is at least as vital 
to our national health, safety and survival 
as any other single resource. The public 
must insist on measures for ensuring 
computer security to the same degree as 
other technologies that are critical to its 
health and safety. 


Reprinted from the Los Angeles Times, OpEd page, 
Sunday, December 4, 1988. At that time, Parrish was 
serving as president of the IEEE Computer Society. 


The opposite of 
common sense 

Behrooz Parhami, 

Carleton University, Ottawa, Canada 

It has been suggested that expert 
systems must be equipped with common 
sense to be truly effective. This is not 
always true. 

For example, an expert system for 
nuclear warfare will probably fail if 
equipped with common sense. After all, 
if the two sides had common sense, they 
wouldn’t have started the arms race, let 
alone a nuclear war! 

I don’t know what the opposite of 
common sense is, but both “uncommon 
sense” and “common nonsense” seem 
appropriate for expert systems controlling 
nuclear warfare. 
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Tutorials 


| Half-Day Sunday, April 23 1 pm - 5 pm 

SuperNode 

John Perry, Bell-Northern Research 

Objective: 

This tutorial is intended to show how SuperNode architecture is used to 
increase the processing capacity of a DMS switch and to evolve the 
DMS from an integrated switching node toward an integrated network 
node. Fundamental to the SuperNode architecture is the high perform¬ 
ance transaction pathway of the DMS-Bus. The DMS-Bus provides the 
communication mechanism between the computing nodes, which may 
be attached and configured as a variety of network-based products, 
such as Signal Transfer Point (STP) and ISDN. Applications of Custom 
Programming and how it is provided within the SuperNode 
architecture will also be discussed. 

Audience: 

This tutorial is aimed at engineers and planners who are responsible 
for both nodal and network traffic and service planning. An under¬ 
standing of central office switching and CCS7 networking is desired, 
but detailed knowledge of call processing or standards is not 
necessary. 

ISDN and BISDN Services and Applications 

Stephen B. Weinstein, Joseph E. Rizzo, Steven E. Minzer, 

Bell Communications Research 

Objective: 

This course will show how ISDN has been introduced and used, as well 
as what applications it has supported and could support. It will de¬ 
scribe the evolution to broadband ISDN in terms of extended signaling 
capabilities, new services, and a range of multimedia, computer- 
supported applications envisioned for the information networks of the 
future. The course is intended to show how ISDN in its present and 
future forms can meet demands for enhanced user control, provide 
personal multimedia communication, data communication, and video 
distribution services now associated with separate networks (if they 
are provided at all), and further the integration of the computer, 
communications, and entertainment worlds. 

Audience: 

This tutorial is designed for individuals on both the provider and user 
sides who are interested in the services and applications potential of 
ISDN and BISDN. The audience should be generally familiar with 

ISDN and at least cognizant of the efforts being made toward BISDN. 
However, detailed knowledge of standards, technology, and 
implementation is not presumed. 


| Full-Day Monday, April 24, 9 am - 5 pm 

Optical Components in Local Area Networks 

Ivan P. Kaminow, Nicholas F. Maxemchuk, AT&T Bell Laboratories 

Objective: 

This course is divided into two parts. In the morning session, the char¬ 
acteristics of a variety of optical components that may be useful in the 
design of networks will be described. In the afternoon session, the 
effect that these components have on network topologies and access 
protocols is described. 

Audience: 

The course is aimed at engineers who are working on, or would like to 
understand, fiber-optic networks. It is assumed that the participants 
are not familiar with the characteristics of fiber-optic components. 

Network Security 

Harold J. Podell, Consultant 

Objective: 

This tutorial presents an overview of recent developments in network 
security, emphasizing the OSI Security Architecture that is being 
developed by the ISO Ad Hoc Group on Security and the Trusted 
Computer System Evaluation Criteria (a DoD standard) being 
developed by the National Security Center. 

Audience: 

Senior technical managers in data processing, information systems, 
and network environments in user organizations; senior development 
staff in hardware and software manufacturers and suppliers; 
and consultants involved in OSI planning and implementation. Prior 
knowledge of computer networking is recommended. 

Bridges and Routers 

Radia Perlman, Digital Equipment Corporation 

Objective: 

A Local Area Network (LAN) allows direct communication between any 
stations directly connected to the LAN. However, technology and 
performance constrain the topology, distance, and number of stations 
on a single LAN. A network therefore usually needs to grow beyond the 
limits of a single LAN. One method of interconnecting LANs is through 
bridges, Two different schemes for interconnecting LANs are being 
standardized by two different subcommittees of the IEEE 802 commit¬ 
tee. The two schemes are spanning treeAransparent bridges and 
source routing bridges. Another method of creating a network with 
multiple links is through routers, which perform the Network Layer 
Protocol as defined by the ISO reference model. These routers also are 
being standardized by various committees. 

Audience: 

No background other than intellectual curiosity is required. Emphasis 
is on protocol concepts rather than on specifics or mathematical 
analysis of the schemes. 
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I Tuesday April 25,1989 

9:30 am - 
10:15 am 

Keynote Address: 

Gedas Sakus 

President, Bell-Northern Research 


10:30 am - 
12:10pm 

1 A. Local Area Networks 

1B. Performance Analysis 
Techniques 1 

1C. Protocol Specification 

and Verification 

ID. Panel: “Applica¬ 

tions and Services in 
High Speed Networks” 

1:30 pm - 
3:10 pm 

2A. Network Routing and 
Flow Control 

2B. Random Access 1 

2C. Distributed Network 

Algorithms 

2D. Panel: “Networks 

for Intelligent Manufac¬ 
turing Systems” 

3:30 pm - 
5:10 pm 

3A. Interconnection 
Architecture 

3B. Panel: “ISDN Confor¬ 
mance Testing” 

3C. Communications 

Protocols 

3D. Distributed Com¬ 

puting Systems of 
Technology 


1 Wednesday April 26,1989 

8:30 am- 
10:10 am 

4A. Time-Token 

Protocols 

4B. Database Systems 
and Network Management 

4C. Panel: “Network 
Security: Present and 
Future Technology” 

4D. Network Modeling 
and Design 

10:30 am- 
12:10 pm 

5A. Integrated Voice/Data 
Networks 

5B. Gateways/Bridges for 
Interconnection 

5C. Panel: “User Access 

to Broadband ISDN: Full 
ATM or Otherwise?” 

5D. Packet Radio 

Networks 1 

1:30 pm - 
3:10 pm 

6A. Panel: “GROUP- 
WARE and Telecommuni¬ 
cation Management” 

6B. Fast Packet Switching 

6C. Error Control and 

ARQ Techniques 

6D. Network Services 

3:30 pm - 
5:10 pm 

7A. Network Architecture 

7B. Panel: “Frame 
Relaying Service” 

7C. Congestion Control 

7D. Load Sharing and 

Balancing 


1 ThursdayApril27,1989 

8:30 am - 
10:10 am 

8A. Real-Time Systems 

8B. MAN Architecture 

8C. Random Access II 

10:30 am- 
12:10 pm 

9A. Lightwave and 
Photonic T echniques 

9B. Performance 
Analysis Techniques II 

9C. Switching 

Techniques 

1:30 pm - 
3:10 pm 

10A. Network Reliability/ 
Security 

10B. Performance 
Evaluation 

10C. Network Design 

and Optimization 

3:30 pm - 

A-AX nm 

11 A. Packet Radio 
Networks II 

11B. Packet Voice 

Systems 

11C. Multiple Access 

Methods 
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Board of Governors approves ties with six international societies 


Sallie Sheppard, Texas A&M University 

Culminating a year that emphasized 
international activities, the IEEE Com¬ 
puter Society Board of Governors fit¬ 
tingly approved establishing affiliate 
relationships with six international soci¬ 
eties during the board’s final 1988 ses¬ 
sion. The board meeting was held 
November 18 in Orlando, Florida, in 
conjunction with the Supercomputing 
88 conference. 

The new affiliates are Koninklijkr 
Vlaamse Ingenieurs Vereniging (Bel¬ 
gium), Association Francaise pour la 
Cybernetique Economique et Technique 
(France), Nederlands Genootschap voor 
Informatica (the Netherlands), Gesell- 
schaft fur Informatik e.V. (Germany), 
Societe Suisse des Informaticiens (Swit¬ 
zerland), and the Computer Society of 
India. 

When the European affiliations are 
finalized, the Computer Society will 
have a liaison with 75 percent of the 
members of European technical socie¬ 
ties in the computing field. 

Presiding at his final board meeting, 
1988 President Ed Parrish noted that 
board emphasis on international activi¬ 
ties during 1988 also involved establish¬ 
ing the Tokyo office and conducting 


Computer Society Executive Committee 
meetings at the Belgium office in the 
spring. 

Parrish also listed other 1988 high¬ 
lights, including forming the Press 
Advisory Board, with Duncan Lawrie 
as its first vice president; approving the 
new Transactions on Knowledge and 
Data Engineering, scheduled to begin 
publication in March; and transmitting 
Compusat 88, the satellite symposium 
organized by the society’s Technical 
Activities Board. 

Parrish noted considerable CS mem¬ 
bership growth during 1988, marking a 
reversal of a general decline witnessed 
over the previous year. 

Computing Research Board report. 

The society’s board heard a report from 
David Gries, chairman of the Comput¬ 
ing Research Board, concerning that 
organization’s plans to represent 
research interests in computer science 
and engineering. 

The CRB was formed in 1986 from 
the Computer Science Board, which 
began in the early 1970s as an out¬ 
growth of the “Snowbird” meetings 
involving department heads from PhD- 


granting institutions. 

The CRB is composed of 24 members 
from academia and industry, each 
member serving a three-year term. The 
academia-to-industry ratio is three to 
one. 

The board’s mission is to work with 
the Computer Society, the ACM, and 
the Society for Industrial and Applied 
Mathematics to find ways to promote 
public understanding and appreciation 
of computing’s potential as an enabling 
technology for other disciplines, pro¬ 
mote an awareness of the critical need 
for computing research (computer 
science and engineering), and present a 
unified case in Washington, DC, to seek 
additional funds for computing 
research. 

The Governing Board then approved 
a resolution calling for cooperation 
with the CRB and subsequently offered 
office space within the society’s Wash¬ 
ington, DC, location for use by the 
CRB staff. 

Appointments. In other society board 
actions, Raymon Oberly was elected to 
continue for a second year as the CS 
ombudsman, Ez Nahourraii was 



Awards presented at Supercomputing conference 


Bruce Shriver received the IEEE 
Computer Society’s Distinguished 
Service Award during an awards 
luncheon at the Supercomputing 88 
conference in Florida. Shriver was 
cited for his work at editor-in-chief of 
Computer. He has served in that post 
since the April 1987 edition. 

Ed Parrish, 1988 president of the 
society, officiated at the luncheon, 
also presenting the following: 

• An Outstanding Contribution 
Award to Paul Hazan for his efforts 
on the successful Compusat sym¬ 
posium. 

• Meritorious Service Awards to 
Willis King and Murali Varanasi. 
(Although not present, Alicja Ellis 
was announced as the winner of a 


Meritorious Service Award for signifi¬ 
cant contributions to chapter 
activities.) 

• Certificates of Appreciation to 
Micha Avni, Mario Barbacci, and J. 
Max Cortner. Avni and Cortner were 
singled out for contributions to chap¬ 
ter activities, and Barbacci for his 
work on TABS. 


Ed Parrish (left) presents Distin¬ 
guished Service Award to Bruce 
Shriver during awards luncheon at 
Supercomputing 88. 
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endorsed for reappointment as editor- 
in-chief of the Computer Society Press, 
and Joe Hootman was endorsed for 
appointment as editor-in-chief of IEEE 
Micro. 

At the conclusion of the meeting, 
incoming President Ken Anderson 
introduced the 1989 Executive Commit¬ 
tee as follows: Joseph Urban, first vice 
president for conferences and tutorials; 
Laurel Kaleda, second vice president 
for technical activities; Duncan Lawrie, 


vice president for CS Press; Gerald 
Engel, vice president for education; Sal- 
lie Sheppard, vice president for publica¬ 
tions; Paul Borrill, vice president for 
standards; Charles Silio, treasurer; and 
Michael Evangelist, secretary (elected 
by the board). 

Additional members include Parrish, 
immediate past president; Helen Wood, 
president-elect; Harriett Rigas, IEEE 
Division V delegate director; Roy 
Russo, IEEE Division VIII delegate 


director; and T. Michael Elliott, execu¬ 
tive director. 

Subsequently, Anderson completed 
the Executive Committee by naming 
Ned Kornfield as vice president for area 
activities and Barry Johnson as vice 
president for membership and infor¬ 
mation. 

The board’s next meeting is slated for 
March 3 in San Francisco during Comp- 
con Spring 89. 


TAB passes resolution to redefine TC membership, permit fee collections 


Laurel Kaleda, Vice President for Technical Activities 


Meeting in Orlando, Florida, during 
Supercomputing 88, the IEEE Com¬ 
puter Society’s Technical Activities 
Board passed a resolution recom¬ 
mending the society’s Board of 
Governors accept a change in CS 
policies and procedures that define 
technical committee membership. 
The Governing Board subsequently 
ratified the resolution. 

TAB usually meets three times a 
year to focus on matters of interest 
to the TC chairs and, consequently, 
encourage more effective technical 
activities for society members. How¬ 
ever, much of TAB’S meeting Novem¬ 
ber 16 was spent discussing future 
actions and direction. 

The approved policy change rede¬ 
fines TC membership into two 
classes: regular and participatory. 
Regular members are CS members 
(both IEEE and affiliate), and par¬ 
ticipatory members belong to a TC 
through involvement in TC activities 
but are not CS members. It is up to 
each TC to decide whether it will 
have participatory members. 

This change in membership defini¬ 
tion also relates to the charging of 
membership fees or dues. It is gener¬ 
ally accepted that, if membership 
fees are charged, CS members 
shouldn’t have to pay as much as 
nonmembers. 

This is a highly controversial sub¬ 
ject that involves not only a redefini¬ 
tion of exactly who is a TC member, 
but also how a TC can deal with its 
own finances and interact with other 
TCs. 

TAB now faces extended discus¬ 
sions on the methods and proce¬ 
dures for dues collection. A number 
of issues need to be answered, 
including the basis for charging 
dues, implementation of dues 
charges, and the way funds will be 
used and accounted for. 

This matter is certain to be the 
major subject of discussion at the 
next TAB meeting, scheduled during 
Compcon Spring 89 in San Francisco 


Wednesday, March 1. 

Those who would like to comment 
on this subject are asked to contact 
Laurel Kaleda, vice president for 
technical activities, at IBM, L43/098, 
5600 Cottle Road, San Jose, CA 
95193, phone (408) 284-3026; or Dave 
Barber, staff administrator for TAB at 
the society’s office at 1730 Mas¬ 
sachusetts Ave., Washington, DC 
20036, phone (202) 371-0101. 

Compusat 88 held. Compusat 88, 
the first state-of-the-art interdiscipli¬ 
nary satellite symposium sponsored 
jointly by TAB and the IEEE Educa¬ 
tional Activities Board (EAB), was 
conducted October 4. (See story in 
the Conferences section.) 

The five-hour event featured short 
technical segments covering seven 
specific subject areas, and high¬ 
lighted the interdisciplinary connec¬ 
tions between them. 

Most exciting was the ability to 
share high-quality presentations with 
so many people simultaneously. Over 
6,000 people at 130 sites in three 
countries (Canada, Mexico, and the 
US) participated in this broadcast. 
Many others will be able to view 
videotapes that will be developed as 
subsets of the broadcast. 

CS Press will be working with TAB 
volunteers to determine the best 
way(s) to take further advantage of 
the information concentrated in 
these sessions. 

Paul Hazan, who chaired the effort 
to produce Compusat 88, was 
honored for this work with an Out¬ 
standing Contribution Award. The 
presentation was made at an awards 
luncheon the same day as the TAB 
meeting. 

Because of the technical and 
financial success of the first such 
symposium, TAB is planning the 
follow-on Compusat 89, and will be 
working with the society and IEEE 
EABs on other related educational 
satellite efforts. 

TABS distributed. The first issue of 


TABS, “A report from the TAB,” was 
published as a supplement to the 
October 1988 issue of Computer. 

Reader response cards received by 
the date of the TAB meeting indi¬ 
cated members were almost uni¬ 
formly positive about this form of 
communication. 

From the TAB point of view, the 
most interesting comment received 
was that TABS is “a good orientation 
... to view the society as more than 
just a way to get subscriptions.” 

This was precisely the purpose of 
TABS: To inform our members of the 
wide variety of activities and 
products of the society—the whole 
range of services to the profession. 

Mario Barbacci, who is also the 
TAB vice chair for planning and 
assessment, provided the guidance 
and direction (“carrot offering and 
verbal 2x4 encouragement") that 
developed and delivered TABS. 

Barbacci’s efforts were recognized 
with a Certificate of Appreciation, 
also presented at the awards 
luncheon. 

With the favorable initial reaction 
to TABS, TAB has decided to move 
forward with another issue. It will dis¬ 
cuss volunteer opportunities and 
how members can get involved with 
the various activities of the society. 

In addition, TABS will carry an in- 
depth survey to help us understand 
the technical interest areas of our 
members, as well as their prefer¬ 
ences for various society services 
and products. Through this mecha¬ 
nism, we hope to be able to make the 
TCs and the activities they sponsor 
more responsive and interesting to 
our members. We also hope to get 
feedback on technical areas that we 
should be starting to work in so that 
we can anticipate the future. 

The year 1988 was a fast-paced 
one for TAB, and 1989 has all the ear¬ 
marks of being faster and more 
active. Please let us know whether 
we’re going in the right directions to 
benefit your professional life, so that 
we can be more effective for you. 
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Cain named to receive first Booth Education Award 


ClaudM. Davis, Awards Committee Chair 


The IEEE Computer Society Board 
of Governors has selected James T. 
(Tom) Cain of the University of Pitts¬ 
burgh to receive the society’s first Tay¬ 
lor Booth Education Award. The 
presentation will be made during the 
society’s Compcon Spring 89 February 
27-March 3 in San Francisco. 

Cain, a senior IEEE member, will be 
cited for “his long-standing and clearly 
outstanding contributions to computer 
science and engineering education.” 

He has been on the faculty at the 
University of Pittsburgh since 1966 and 
is currently associate professor of elec¬ 
trical engineering in the School of 
Engineering. 

Cain has served in a number of IEEE 
and Computer Society posts and cur¬ 
rently chairs the Computing Science 
Accreditation Board as well as accredi¬ 
tation activities of the IEEE Educa¬ 
tional Activities Board. As an alternate 
member of the Accreditation Board for 


Engineering and Technology, he coor¬ 
dinates all ABET accreditation activi¬ 
ties. He has been heavily involved in the 
development of program criteria, visitor 
selection, and training for both ABET 
and CSAB. 

Among a number of prior honors 
Cain has received is the society’s Distin¬ 
guished Service Award for “continued 
leadership as vice president for publica¬ 
tions and as acting president during the 
fourth quarter of 1986-87.” 

The CS board established the annual 
award to honor the memory of the late 
Taylor L. Booth, who, prior to his 
death in October 1986, was a computer 
science and engineering professor at the 
University of Connecticut and director 
of the university’s Computer Applica¬ 
tions and Research Center. 

Booth had been active in the Com¬ 
puter Society for over 16 years, particu¬ 
larly in the educational activities area. 
Those activities included many years of 


CS computer bridge tournament slated 


The IEEE Computer Society is spon¬ 
soring a computer bridge tournament 
and is inviting all interested members to 
develop bridge-playing programs so 
they can compete in the event. The 
competition is scheduled during CAIA 
89, the society’s Fifth International 
Conference on Artificial Intelligence 
Applications March 6-10 in Miami, 
Florida. 

The tournament will be subdivided 
into two segments, a bidding contest 
and a playing contest. Contestants may 


take part in either or both contests. 
Awards will be presented to the overall 
winner, the bidding contest winner, and 
the playing contest winner. 

To encourage student participation, a 
special award will be given to the best 
student team. All student teams spon¬ 
sored by society student chapters will be 
eligible to compete for this award. 

Each player in a given game will be 
simulated on an independent computer. 
Therefore, each team will need at least 
two—and preferably four—computers 


ICCP marks its 15th anniversary 


The Institute for Certification of 
Computer Professionals, a nonprofit 
organization representing the IEEE 
Computer Society and 13 other national 
and international computer societies, 
celebrated its 15th anniversary with a 
reception and dinner in Rosemont, 
Illinois. 

David H. Jacobsohn and Marshall C. 
Yovits, the Computer Society’s two 
representatives on the ICCP board of 
directors, were among the 66 persons in 
attendance. Jacobsohn was one of the 
organization’s original committee 
members. 

The three fellows of the ICCP, Paul 
Pair, Coleman Furr, and Rear Admiral 


Grace M. Hopper, USNR (Ret.), plus 
former executive secretary Jamie Fox, 
were honored at the event for their con¬ 
tributions to the ICCP. 

The program also included a video¬ 
tape on the history of the ICCP, which 
was founded in 1973 to test and certify 
knowledge in the computer and infor¬ 
mation systems industry. Offices are 
located in Des Plaines, Illinois. 

David Jacobsohn (left) and Marshall 
Yovits, who represent the IEEE Com¬ 
puter Society on the ICCP board, were 
on hand to help the institute observe its 
15th anniversary. 



Tom Cain will be the first recipient of 
the Computer Society Taylor Booth 
Award at Compcon Spring 89. 


service in computer engineering and 
curriculum development and as a 
founding member and the first presi¬ 
dent of the CSAB. 


so that no particular security measures 
will be required when hands are to be 
replayed after switching positions. 

Specific rules will govern bidding, 
bidding conventions, psyching, lead and 
carding styles, scoring, response time, 
penalties, etc. 

To obtain further information about 
the bridge contest, circle Reader Service 
No. 185. For information about student 
membership and/or forming student 
chapters, circle No. 203. 
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NEWS FROM THE COMMITTEE ON PUBLIC POLICY 
Experts Directory—A project for 1989 

Ray Oberly, COPP Experts Directory Chair 


Until now, the Committee on Public 
Policy has had to scramble for experts 
when the call came to analyze a public 
policy stand, present testimony to con¬ 
gressional or other committees, or com¬ 
ment on some pending or enacted 
legislation on behalf of the IEEE Com¬ 
puter Society. For years, we have been 
toying with the idea of establishing a 
centrally maintained experts directory 
for use by the society’s Membership and 
Information Committees. 

Four years ago, when we first con¬ 
ducted a survey on this subject, we 
asked people to identify themselves as 
experts in fields for which they would 
be willing to publicly testify. Eleven 
members answered the call. From this 
humble beginning, we hope to increase 
the list tenfold in the coming year. 

The COPP Experts Directory data¬ 
base being developed will contain the 
names of Computer Society members 
and affiliates who, because of their 
expertise, can be called on short notice 
to lend their professional opinions on 
subjects undergoing public scrutiny in 
the press, the US Congress, or other 
governmental bodies. 

Data will be solicited from members 
of fellows rank, officers, technical 
chairpeople of the society at large, and 
volunteers who answer a call issued by 
COPP to participate in this vital proj¬ 
ect. (You can request a short question¬ 
naire by circling number 187 on the 
reader response card in this issue of 
Computer.) The information gathered 
will be used solely by committee mem¬ 
bers, who will also be responsible for 
annually reviewing the information. 

Actually, the most difficult task in 
creating the experts directory was com¬ 
ing up with a simple coding system so 
the proper experts can be sought in the 
database. The scheme adopted to fill 
the bill was to take the three major CS 
Technical Committee breakdowns 
(hardware, software, and applications) 
and use them with another category for 
the miscellaneous type of items that do 
not easily fit into the three major TC 
groupings. 

Thus, the questionnaire that will be 
mailed out in the first quarter of 1989 
will request categorizations as follows: 


1.00 Hardware 

1.01 Computer architecture: Integrated 
hardware and software design of 
general- and special-purpose digital 
computers 

1.02 Computer communications: Sys¬ 
tems that integrate computing func¬ 
tions and telecommunications 
facilities 

1.03 Computer elements: Circuits, mem¬ 
ories, I/O devices and systems, and 
their interrelationships 

1.04 Computer packaging: Physical 
design problems of building com¬ 
puters and large circuit assemblies 

1.05 Distributed processing: Technical 
aspects of specifying, designing, 
implementing, and evaluating dis¬ 
tributed computing systems 

1.06 Fault-tolerant computing: Design, 
analysis, testing, verification, and 
evaluation of systems subject to 
faults that occur during design and 

1.07 Mass storage systems and technol¬ 
ogy: Organization, storage, and 
retrieval, and hardware require¬ 
ments of large data collections 

1.08 Microprocessors and microcom¬ 
puters: Architecture, design, and 
application of microprocessors and 
microcomputers 

1.09 Microprogramming: Micropro¬ 
gramming and its support tools 

1.10 Optical processing: Application of 
optics to data storage, processing, 
and communications 

1.11 VLSI: Interaction between the semi¬ 
conductor process and system 
design on VLSI 

1.12 Multiple-valued logic: Research in 
the theory and application of many¬ 
valued systems 

2.00 Software 

2.01 Computer display and ergonomics: 
Ergonomics criteria for computers 

2.02 Computer languages: High-level 
programming languages including 
requirements, specification, design, 
test, and query languages 

2.03 Data engineering: The role of data 
in.the design, development, 
management, and utilization of 
information systems 

2.04 Mathematical foundations of com¬ 
puting: The mathematics underlying 
the power, complexity, and design 
of computing devices, algorithms, 
and programs 

2.05 Operating systems: Theoretical and 
practical aspects of operating sys¬ 
tem design and organization, 


resource allocation policies, mea¬ 
surement, performance evaluation, 
and system reliability 

2.06 Pattern analysis and machine intelli¬ 
gence: Pattern recognition, artificial 
intelligence, expert systems, natural 
language understanding, image pro¬ 
cessing, and computer vision 
2.07 Security and privacy: Operating sys¬ 
tems security, data encryption, 
access control mechanisms, data¬ 
base protection, network security, 
and other aspects of protection in 
computer systems 

2.08 Simulation: Research, development, 
methodologies, and applications of 
mathematical modeling, and analog 
and digital computer simulation 
2.09 Software engineering: Application 
of engineering methods and princi¬ 
ples to the development of com¬ 
puter software, including associated 
techniques and tools 

3.00 Applications 

3.01 Computational medicine: Computer 
science and engineering applied to 
medical and health services 
3.02 Computer graphics: Computer 

graphics and graphic applications to 
science, engineering, business, and 

3.03 Computing and the handicapped: 
Use of computer technology in the 
rehabilitation, education, and 
employment of handicapped 
persons 

3.04 Computers in education: Evaluat¬ 
ing, specifying, designing, and 
implementing hardware and soft¬ 
ware forming educational comput¬ 
ing systems 

3.05 Design automation: Use of 

computer-oriented techniques in all 
aspects of the design process, with 
emphasis on design languages, logic 
synthesis, verification techniques, 
manufacturing interface data, 
graphics, and database management 
3.06 Oceanic engineering and technol¬ 
ogy: Application of computers and 
technology to ocean-related matters 
and marine environments 
3.07 Office automation: Computer tech¬ 
nology used to support and auto¬ 
mate office activities 
3.08 Personal computing: Development 
and application of personal- 
computer technology in industry, 
business, and education 
3.09 Real-time systems: Hardware and 
software related to using computers 
in real-time data systems, operating 
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systems, processing of acquired 
data, database management, pro¬ 
cess control, data acquisition net¬ 
works, industrial systems, and data 
communications in both distributed 
and parallel environments 

3.10 Robotics: Control systems, pro¬ 
gramming languages, planning and 
spatial reasoning, interpretation of 
sensor signals, application of 
machine vision to robot control, 
and interaction with CAD/CAM 
functions 

3.11 Supercomputing applications: The 
relationship of scientific and mathe¬ 
matical disciplines and their imple¬ 
mentation on supercomputers 

3.12 Test technology: A11 aspects of 
system-, board-, and device-testing 
with design, manufacturing, and 
field, including the hardware and 
software tools needed to do testing 

4.00 Other 

4.01 Employment: Employment prac¬ 
tices concerning computer profes¬ 
sionals, tax reform, foreign 
engineers, and related matters 

4.02 Standards: Used in conjunction 
with the other expertise codes 

4.03 Computer ethics and social issues: 
Impact of computers and their 
usage/misusage on the quality of 
life 

4.04 Property: Intellectual property pro¬ 
tection, copyright laws, technology 
transfer, transnational information 
exchange 

4.05 Software safety: Quality assurance, 
licensing, and safety aspects of 
computers and programs for the 
medical profession, navigational 
equipment, the space shuttle, 
atomic reactors, air traffic control, 

4.06 Education/computer literacy: As 
applied to the computer industry, 
including computer-based tools, 
accreditation legislation, and public 
misconceptions 

COPP urges all computer profes¬ 
sionals to participate in public issues, 
especially those that impact our profes¬ 
sion. While the legislation being 
addressed is purely US-based, the 
issues, whether they’re related to prop¬ 
erty protection, safety, ethics, or a host 
of other subjects, have worldwide uses 
and implications. Thus, the COPP 
Experts Directory should contain mem¬ 
bers from all countries. 

Unless our professional opinions are 
heard—both in the press and in public 
hearings—before technically unenforce¬ 
able or incorrect laws are enacted that 
affect our well-being, we cannot com¬ 
plain about the consequences. 


UPDATE 


Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues 
to Update Editor, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720, or to Bruce Shriver, Editor-in-Chlef, Dept, of Decision 
Sciences, University of Hawaii, 2404 Maile Way, Honolulu, HI 96822. 


EIAJ reports increased US chip sales in Japan 


US semiconductor manufacturers are 
making significant inroads in the 
Japanese market, according to a recent 
statement released by the Electronic 
Industries Association of Japan, which 
claims that any sales shortfalls by US 
chip makers are attributable to a product 
“mismatch” between US output and 
Japanese demand. 

“We believe real progress is being 
achieved by US companies,” said Iwao 
Ojima, EIAJ president, during a Tokyo 
press briefing accompanying release of 
the statement. “Foreign semiconductor 
sales to Japan have increased by 87.5 
percent in the past two years at a pace far 
surpassing the rate of growth in the 
overall Japanese market.” 

In the statement, EIAJ refutes allega¬ 
tions that Japan is violating the market 
access provisions of the 1986 US-Japan 
semiconductor arrangement and that 
Japanese companies are engaged in 
anticompetitive pricing and supply 
manipulation in the dynamic-RAM 
market. 

The statement addresses differences 
between the US and Japanese semicon¬ 


ductor industries in structure, business 
strategies, approach to investment, 
technological development and product 
output. The EIAJ maintains that these 
differences have resulted in a product 
mismatch between US production output 
and Japanese buyer demand. 

The two industries developed different 
areas of product specialization in 
response to the commercial environments 
in which they grew, the group states. As a 
result, today’s US semiconductor output 
is mismatched with about 50 percent of 
the Japanese semiconductor market. 

Citing statistics showing that more 
than 75 percent of US advances in 
Japanese market share are concentrated 
among five US companies (Texas 
Instruments, Motorola, Advanced Micro 
Devices, Intel, and National Semiconduc¬ 
tor), Ojima called on other US companies 
to participate in outreach and purchasing 
programs developed to boost sales of 
foreign semiconductors in Japan. 

“EIAJ believes that a healthy and 
vigorous US semiconductor industry is an 
essential element in the world electronics 
industry,” said Ojimo. 


R&D spending key to Japanese growth 


Japan’s technological growth between 
1965 and 1985 owes much to hefty 
annual increases in research and develop¬ 
ment spending, according to a National 
Science Foundation report. 

“The Science and Technology 
Resources of Japan: A Comparison with 
the United States” states that R&D 
spending in Japan increased annually by 
an average of 9.3 percent while the 
country’s gross national product in¬ 
creased by an average of 6 percent. 
During the same period, US R&D 
spending increased by an average of 2.5 
percent yearly, and GNP grew by an 
average of 2.8 percent. 

The report states that the US spends 
more on R&D and employs more 
scientists and engineers than Japan, 
although the two nations spend compa¬ 
rable proportions of their national 
incomes on R&D and employ a similar 
number of scientists and engineers per 
capita. 


However, differences exist in the types 
of scientists and engineers that dominate 
the two countries. For example, Japan 
trains relatively more engineers but far 
fewer natural scientists. Also, Japanese 
industry provides a larger share of R&D 
funding (69 percent in 1985) than does 
US industry (49 percent). 

The report attributes such skewed 
percentages to disproportionate defense 
spending between the two countries. 
Japan spends about 1 percent of its R&D 
money on defense, compared with 30 
percent in the US. 

Also, the Japanese government 
traditionally has not given industry R&D 
funds. About 2 percent of industrial R&D 
is funded by the Japanese government. 
The US government provides about one- 
third of its country’s industrial R&D. 

Copies of the report (NSF 88-318) are 
available from the NSF Division of 
Science Resources Studies, 1800 G Street 
NW, Washington, DC, 20550. 
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Advance Program for ASPLOS-III 


—j— 

SIGARCH 

SIGPLAN 

SIGOPS 

Monday, April 3 

Tutorial I: Cache Consistency and Shared Memory 
Multiprocessors, Jim Goodman, University of Wisconsin 
Discussion of recent developments in memory design for 
shared-memory multiprocessors. Review of critical cache 
design choices, both for single and multiple processors. 
Included will be consideration of multiple levels of cache, 
stale data problem, multiple buses, and synchronization 
primitives as an extension to cache consistency solutions. 
Several case studies of multiprocessor systems will be 
presented. 

Tutorial II: Program Analysis and Restructuring for 
Concurrency, Ron Cytron, IBM 

Examination of automatic restructuring of programs for 
architectures that support various forms of concurrent 
execution. Topics include: data and control dependence 
analysis techniques for discovering parallelism in sequential 
programs, restructuring techniques for improving the 
effectiveness of such analysis, and architectural-specific 
transformations for exploiting a variety of concurrency 
features. The tutorial will include recent work related to 
memory hierarchies and shared-memory parallel programs. 

Tuesday, April 4 

Keynote Address: Ken Thompson, AT&T Bell Labs 
Session I: Wide Instruction Word Machines 
“Architecture and Compiler Tradeoffs for a Wide Instruction 
Word Microprocessor,” Thomas Gross, Robert Cohn, P.S. 
Tseng, Carnegie-Mellon University, Monica Lam, 
Stanford University 

“Tradeoffs in Instruction Format Design for Horizontal 
Architectures,” Gurindar Sohi, S. Vajapeyam, University of 
Wisconsin-Madison 

“Overlapped Loop Support in the Cydra-5,” James C. 
Dehnert, Peter Y-T. Hsu, Joseph P. Bratt, Cydrome 
Session II: Synchronization 

“Architecture Support for Synchronous Task 
Communication,” Forbes Burkowski, G.V. Cormack, 
G.D.P. Dueck, University of Waterloo 
“The Fuzzy Barrier: A High Speed Mechanism for 
Synchronization of Processors,” Rajiv Gupta, North 
American Philips 

“A Set of Efficient Synchronization Primitives for a Large- 
Scale Shared-Memory Multiprocessor,” James Goodman, 


TC MM 
TC VLSI 
TC OS 

Phil J. Woest, Mary K. Vernon, University of Wisconsin- 
Madison 

Session III: Support For Debugging 

“A Software Instruction Counter,” Thomas LeBlanc, John 

Mellor-Crummey, University of Rochester 

“Efficient Debugging Primitives for Multiprocessors,” Ilya 

Gertner, Ziya Aral, Greg Schaffer, Encore Computer 

“Sheaved Memory: Architectural Support for the State 

Saving and Restoration in Paged System,” Mark Staknis, 

Northeastern University 

Conference Banquet: New England Aquarium 

Wednesday, April 5 

Session IV: Operating System Issues 
“Reference History, Page Size, and Migration Daemons in 
Local/Remote Architectures,” Mark A. Holliday, Duke 
University 

“Translation Lookaside Buffer Consistency: A Software 
Approach,” David Black, Richard Rashid, David Golub, 
Charles Hill, Robert Baron, Carnegie-Mellon University 
“Failure Correction Techniques for Large Disk Arrays,” 
Garth Gibson, Lisa Hellerstein, Richard Karp, Randy Katz, 
David Patterson, University of California-Berkeley 
Session V: Instruction Sets 

“A Unified Vector/Scalar Floating-Point Architecture,” 
Norman Jouppi, Jonathan Bertoni, David W. Wall, Digital 
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Computer Society windowing standards group forming 


Sunii Mehta, Convergent Technologies 
A standards development working 
group is being formed under the IEEE 
Computer Society Technical Committee 
on Operating Systems (TCOS) to define 
a high-level interface to windowing for 
application and user portability. 

This effort is based on the X Window 


System model of windowing. It will 
focus on the user interface toolkit level 
of application interface for program 
portability at the highest level and on 
the “drivability” of applications built 
with user interface toolkits. 

Such a standard would be useful 


because it could contribute to portabil¬ 
ity by allowing users to easily without 
retraining move between applications 
and systems from different vendors. 
Portability is likened to the ease with 
which people can drive automobiles 
made by different manufacturers. 


Technical background on the X Window System 


• visual appearance of widgets, and 

• opening and closing of windows. 

Another component of the style guide 
describes the feel or drivability of an 
application at a lower level. It describes 
how each type of widget interacts with 
the user. For example, to select text 
within a text widget, position the cursor 
at the start of the section to be deleted, 
hold the left mouse button down, and 
move the cursor to the end of the sec¬ 
tion to be deleted. Releasing the mouse 
button will highlight the selected text. 
Another way to describe drivability 
relates to the set of user interface 
actions used to interact with widgets. 

The driver analogy is based on 
similarity to operating a car. Turn sig¬ 
nals and break-pedal location, two user- 
safety features, are standardized in 
most cars. But the location of the light 
switch and the method of removing the 
key, two features not crucial to drivabil¬ 
ity, are not standardized. 


Sunii Mehta, Convergent Technologies 


The X Window System is a network 
window system with three essential 
components: clients, servers, and the X 
Window protocol (Figure 1). 

An X Window server provides window¬ 
ing services to clients. The server 
“owns” the screen, keyboard, and 
mouse. It manages windows that, at its 
level, are possibly overlapping rectangu¬ 
lar areas of a bitmapped screen within 
which clients can draw and write text. 

The X Window protocol is used to 
communicate between servers and 
clients, two entities that often run on 
different nodes of a local area network. 
This protocol requires the availability of 
a reliable transport protocol, such as 
TCP/IP (transmission control pro¬ 
tocol/Internet protocol) or an Open Sys¬ 
tems Interconnection (OSI) protocol, to 
provide basic communication services 
between the client and the server. 

Several different clients running on 
different nodes of a LAN can use a sin¬ 
gle display server to interact with a user. 

X Window clients are applications 
that use the X Window System to inter¬ 
act with the user. These clients typically 
consist of several layers of software 
(see Figured). At the lowest level are 
routines used to provide a functional 
interface to the X Window protocol. 
These routines, referred to as the X 
library, or Xlib, establish network con¬ 
nections with servers, compose protocol 
packets, transmit the packets to the 
servers, and receive replies. 

The layer of routines above Xlib pro¬ 
vides routines that manage higher level 
user interface objects called widgets. 
Such widgets provide a specific user 


interface service and possess a distinc¬ 
tive visual appearance and a well- 
defined response to user input. 

A button is a simple example of a 
widget. It appears on the screen as a 
rectangle with rounded corners and 
internal explanatory text. If a mouse but¬ 
ton is clicked when the screen cursor is 
within the button, it inverts momentarily 
and typically also calls a software rou¬ 
tine associated with it to carry out an 
application specification. The X intrin- 
sics layer provides functions that allow 
an application to create, modify, and 
destroy widgets. 

The first two layers are common to 
most X Window applications. The next 
layer, termed the toolkit layer, consists 
of a set of predefined widgets often 
used by programmers in building appli¬ 
cations. Most toolkits provide buttons, 
one-of-many checkboxes, many-of-many 
checkboxes, text entry and edit fields, 
scroll bars, and list boxes. Application 
writers can pick and choose from the 
array of widgets a toolkit offers or con¬ 
struct their own custom widgets by 
using the X intrinsic routines. 

Although not a software layer, the 
style guide is a very important compo¬ 
nent of an application. For the sake of 
conformance, this style describes the 
overall “look and feel” of an application. 
Typical “look and feel” components are 

• overall visual appearance of the 
screen 

• appearance and positioning of 
icons, 

• composition and layout of dialog 
boxes 


Drivability is called out separately 
from look and feel because a standard 
for application drivability is the key to 
greater user portability. It is particularly 
important in the network-based X Win¬ 
dow System because a user may be 
presented with windows from different 
applications and different systems at 
any time. If each of these systems used 
a different standard for drivability, the 
user would be very confused and would 
likely make a serious error. If however, 
these applications conformed to a stan¬ 
dard for drivability, a user could easily 
switch between them without erring. 
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Windowed applications need high- 
level services such as buttons, menus, 
scroll bars, and edit fields provided by 
user interface toolkits in the X Window 
System model. These common services 
require specific procedural interfaces to 
programming languages so that applica¬ 
tions using these services can be ported 
from one system to another. The devel¬ 
opment of such procedural interfaces 
for application portability will be part 
of the new group’s work program. 

The group’s efforts will also focus on 
user portability through a specification 
for application drivability. Drivability 
can be characterized as the set of stan¬ 
dard user actions used to invoke appli¬ 
cation capabilities. It can also be 
described as part of the feel of the 


application at a micro level. 

Drivability involves the actions used 
to interact with toolkit objects dis¬ 
played on the screen, as in “Click the 
left mouse button to check the check¬ 
box.” It does not involve the appear¬ 
ance of the screen or how icons are 
opened into windows. 

The concept of drivability is impor¬ 
tant in the X Window System because a 
user may be presented simultaneously 
with windows from different applica¬ 
tions and different systems. While there 
is ample room for creative variations 
between applications, using a set of 
common user interface actions enhances 
user portability and decreases the 
chance of user error. Application and 


user portability are linked because the 
design and implementation of a user 
interface toolkit needs to reflect stan¬ 
dard drivability considerations. 

Robert Schelfler, director of the X 
Consortium, said he was “pleased to 
see broad acceptance of the work done 
by the X Consortium and interest by 
accredited standards bodies in ratifying 
it as a de jure standard.” 

The group plans to conduct its first 
meeting in the latter part of January. 

To participate or obtain more informa¬ 
tion (including the specific date and 
location of the meeting), contact Sunii 
Mehta, Convergent Technologies, 2700 
N. First St., San Jose, CA 95151, phone 
(408) 435-3487. 



Look and feel 
(e g. Screen layout) 

Drivability (dick left mouse 
button to select object) 

Application 

Style guide 

Application 


High-level application 
interface (Widgets) 

Toolkit | 1 | 2 

1: Vendor extensions 

2: Application extensions 

Low-level application 

X intrinsics 


interface (Widget mgmt) 

Data stream primitives 

X library (Xlib) 


Data stream encoding 

X 11 Protocol 



Figure 2. The X Window System’s client structure. 


Companies negotiate 
interface agreement 

GenRad and CAD Language Systems 
have struck a phased development and 
joint marketing agreement to develop 
and market an IEEE Standard VHSIC 
hardware description language (VHDL) 
interface to GenRad’s system Hilo logic 
verification and test development envi¬ 
ronment. 

The results of the first phase of this 
effort will enable engineers to represent 
their designs in VHDL and validate the 
logical behavior with the system Hilo 
Simulator. Subsequent phases will 
result in simulation support for the full 
IEEE Standard VHDL, as well as sup¬ 
port for all system Hilo capabilities, 
including dynamic timing analysis, fault 
simulation, and test generation. The 
agreement will also enable current Hilo 
users to communicate their designs to 
others in IEEE VHDL. 

CAD Language Systems designed the 
standard under sponsorship from the 
very high speed integrated circuit 
(VHSIC) program. As part of the stan¬ 
dardization effort, the company devel¬ 
oped the final definition of the IEEE 
Standard 1076-1987 that was balloted 
and approved in December 1987. 

The IEEE Computer Society’s Tech¬ 
nical Committee on Design Automation 
sponsored development of the VHDL 
standard in cooperation with IEEE 
Standards Coordinating Committee 20 
(Abbreviated Test Language for All 
Systems—ATLAS). 

Copies of the standard can be 
ordered by contacting the CS Press at 
(800) CS-BOOKS [in California, dial 
(714) 821-8380] and specifying order 
No. 983. The price to Computer Society 
and/or other IEEE members is $36 ($40 
to nonmembers). 
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Editor: Richard Eckhouse, MOCO. Inc:, PO Box A, 91 Surfside Rd. Scituate, MA 02055; Compmail+, r.eckhouse 


Applying artificial intelligence 

Michael M. Dediu, Dediu Computer Consultants 


Techniques of artificial intelligence 
applied to real problems result in practi¬ 
cal, economic, and reliable solutions. 
Many companies, ranging from com¬ 
puter makers to small businesses to oil 
companies, are developing AI expertise. 
Moreover, the number of AI tools 
available is growing at a significant 
rate, with the PC software market 
offering a variety of AI tools and 
products for the entire spectrum of 


computers. 

The most frequent applications of 
AI—expert systems—perform a wide 
variety of roles. They can serve as 
training systems, job performance 
supporters, or stand-alone monitor¬ 
ing systems. Expert systems have 
the main advantages of improving 
productivity, lessening errors, lower¬ 
ing costs, raising quality, and 
increasing throughput. 


AI has a huge theoretical foundation, 
and many concepts are quite sophisti¬ 
cated and difficult to understand with¬ 
out adequate training. However, the 
new products—like those presented 
here—take a practical approach, 
eliminating most of the specialized ter¬ 
minology. It appears quite obvious that 
those who begin to adopt and apply AI 
will gain a significant competitive 
advantage. 


GoldWorks—an expert system development tool for PCs 


As I’ve said, artificial intelligence— 
especially expert systems—has begun to 
address practical applications, even at 
the personal computer level. A good 
example is GoldWorks, a knowledge- 
based expert system development tool 
from Gold Hill based on the company’s 
Golden Common Lisp (GCLisp) 
Developer software. 

GoldWorks allows you to develop 
expert system prototypes and end-user 
applications. Because it has a multilevel 
architecture, you can progressively 
develop more complex applications. 

GoldWorks has quite an elaborate 
theoretical base, and I will omit many 
of the details in this review. The major 
components of an expert system are the 
knowledge base and the inference 
engine. The knowledge base contains 
the representation of the information 
necessary for a specific expert system. 
The inference engine contains the rules 
applied to the knowledge base. The 
inferencing techniques available in 
GoldWorks are forward chaining, back¬ 
ward chaining, and goal-directed 
forward-chaining. 

GoldWorks runs on the IBM PC-AT 
and compatibles and on the Humming- 


board (a 16- or 20-MHz 80386 board 
with 6 to 24 Mbytes of memory). Mem¬ 
ory requirements are 512 Kbytes of 
main memory and 5 Mbytes of extended 
memory (10 Mbytes of hard-disk mem¬ 
ory). The company recommends an 
EGA display, but the program also 
works with a monochrome monitor or 
CGA display. 

I found GoldWorks’ two interfaces 
quite appropriate for different categor¬ 
ies of users. The menu interface suits 
people with no programming experience 
who want to create applications without 
Lisp. The developer’s interface gives 
more advanced programmers access to 
GoldWorks’ open architecture through 
Lisp or the GMACS editor. In the 
developer’s interface, you can use the 
GMACS editor; write, test, and debug 
applications; write rule predicates and 
Lisp functions; and use object pro¬ 
gramming. 

GoldWorks uses three knowledge 
representation techniques: frames (for 
structuring and organizing data), for¬ 
ward and backward chaining (for 
searching for solutions), and object 
programming (for associating Lisp 
functions with frame objects). 


The installation, although not diffi¬ 
cult, takes about half an hour. The sys¬ 
tem includes 31 diskettes and five 
manuals. When you enter the menu 
interface, you get a screen with a com¬ 
mand line across the top; this command 
line lists the major commands necessary 
for development. 

The first command on the command 
line is System. When you choose it, a 
list of several items appears under it. 
One of them—Load—loads the system. 
The Define command gives a list of 
what you can define: relation, frame, 
instance, sponsor, rule, rule-set, asser¬ 
tion, attempt. 

GoldWorks offers the additional fea¬ 
tures of a tutorial, an on-line help sys¬ 
tem, the screen toolkit, a Lotus 1-2-3 
(V.2) interface, and a dBase III 
interface. 

GoldWorks’ tutorial teaches some 
ideas from expert system technology 
and knowledge engineering. To get to 
this tutorial quickly, after installation 
move to the menu interface (by typing 
Ctrl-A), select System, and choose 
Tutorial on the popup menu. You can 
use a mouse or keyboard commands to 
move the cursor. 
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The screen toolkit facility helps create 
a window where you can see the results 
from a running program. 

The documentation is extensive and 
well done. It uses a good method to 
facilitate understanding of 
GoldWorks—the hands-on example. 
One such example concerns the budget 
allocation process in a small company. 
For this you need several rules plus 
information upon which the rules can 
act. This information must be struc¬ 
tured and represented with frames and 
instances. You can assign a priority to 
each rule. 

Even a simple example demonstrates 
the need for patience in handling all the 
details of putting data into the expert 
system. The terminology used in the 
documentation is sometimes inap¬ 
propriate, but the diagrams are clear 
and helpful. 

The rule editor screen is quite simple. 

I like the fact that when you close a 
parenthesis the system displays a rectan¬ 
gle over the matching open parenthesis, 
so you can check that all the open 
parentheses are closed. 

GoldWorks is a complex software 
product and requires extensive effort to 
analyze all its capabilities. I thought it a 
good expert system development tool, 
useful for anybody interested in this 
new field of computer applications. It 
costs $7,500 for one copy and $4,990 
each for three copies. For those users 
requiring assistance, Gold Hill’s Educa¬ 
tion Services offers a variety of pro¬ 
grams that teach GoldWorks and 
related subjects. Contact Gold Hill 
Computers, 26 Landsdowne St., Cam¬ 
bridge, MA 02139, phone (617) 
621-3300. 

Reader Service 21 


GoldWorks AXLE-a 
learning tool for developing 
expert systems 

The design and development time for 
expert system applications is quite sig¬ 
nificant. GoldWorks AXLE helps, 
through a programming-by-example 
process, to reduce this development 
time. (AXLE stands for Albathion 
Expert Learning Environment.) It 
demonstrates actual diagnostics and 
planning applications for manufactur¬ 
ing, aerospace, and oil exploration. 

GoldWorks AXLE provides users 
with the ability to copy and modify 
source code in GoldWorks and to 
develop their own applications. It also 
includes detailed instructions on how to 


implement common problem-solving 
techniques. 

A useful feature of GoldWorks 
AXLE that accelerates the development 
process is the inclusion of code modules 
that you can embed in your own appli¬ 
cation. A module consists of a separate 
source code file containing all of the 
Lisp functions and GoldWorks objects 
and handlers required to recreate spe¬ 
cific features of an AXLE application. 
This source code contains components 
of the example expert systems, such as 
simulation (modeling the environment 
to be analyzed); Gantt charts (contain¬ 
ing a box for each event in a process); 
model editors (graphic interface con¬ 
trolling all aspects of creating, editing, 
and viewing); and data collection. 

A graphics toolkit lets you build end- 
user interfaces to your application. The 
graphics toolkit has both a menu-driven 
interface for nonprogrammers and a 
programmatic interface for Lisp 
programmers. 

GoldWorks AXLE can be used 
independently. In this case, it offers an 
introduction to expert system develop¬ 
ment. This exposes users to the actual 
development process from beginning to 
end. 

GoldWorks AXLE is an advanced 
learning environment that emphasizes 
real world examples. This helps to 
reduce the training time. These exam¬ 
ples demonstrate methods for decision 
making about discrete tasks and 
resources under certain constraints, 
such as time, finances, and quality, and 
for notifying operators of mechanical 
problems requiring equipment main¬ 
tenance or shutdown. 

The main features of GoldWorks 
AXLE are the navigator (which 
explains how an application is devel¬ 
oped), the browser (which allows in- 
depth examination of the details of the 
sample application), diagnostic and 
planning applications (including manu¬ 
facturing, aerospace, and oil explora¬ 
tion applications, with complete source 
code), a GoldWorks tutorial (which 
shows the construction of an applica¬ 
tion using GoldWorks), and a graphics 
toolkit (for building a graphical inter¬ 
face to a GoldWorks knowledge base). 
AXLE can be used as a stand-alone tool 
or on top of GoldWorks. 

The system requirements for the 
stand-alone version are an IBM PC-AT 
or compatible, 512 Kbytes of base mem¬ 
ory, 5 Mbytes of extended memory, 7.5 
Mbytes of free space on a hard disk, 
CGA display adapter and monitor, and 
PC-DOS or MS-DOS. When you com¬ 
bine AXLE with GoldWorks, you need 
an additional 2 Mbytes of extended 
memory and an additional 3.5 Mbytes 


of free space on the hard disk. A point¬ 
ing device, such as a Microsoft or 
Mouse System mouse, is recommended. 

The documentation contains four 
manuals: AXLE User’s Guide, AXLE 
Graphics Toolkit Manual, AXLE Diag¬ 
nostics Library Manual, and AXLE 
Planning Manual. 

GoldWorks AXLE costs $1,995. 

All in all, GoldWorks AXLE is a use¬ 
ful tool that teaches you, through exam¬ 
ples, how to develop expert systems. 
Contact Gold Hill Computers, 26 
Landsdowne St., Cambridge, MA 
02139, phone (617) 621-3300. 
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ALS Prolog—a professional 
compiler for MS-DOS 
computers 

One of the most used languages in 
artificial intelligence is Prolog. Applied 
Logic Systems released the Professional 
Version 1.2 of its ALS Prolog compiler 
for computers running MS-DOS. ALS 
Prolog is based on Edinburgh style syn¬ 
tax and produces exceptionally fast 
code. 

Programmers often gauge the speed 
of Prolog systems with a naive reverse 
benchmark that calculates the LIPS 
(logical inferences per second) for a 
number of list elements. The company 
provides the source code for the bench¬ 
mark (Nrev.pro). I ran this benchmark 
with 40 elements and two iterations on a 
10-MHz AT-compatible and got 
15,672.7 LIPS. This figure is signifi¬ 
cantly higher than any Prolog 1 have 
tested for interpreted and compiled 
code. On the same initial values another 
Prolog reached 498.3 LIPS in inter¬ 
preted mode and 10,774 LIPS with 
compiled code. ALS states that Nrev 
returns 3,400 LIPS on a PC-XT and 
31,000 LIPS on a 16-MHz Compaq 386 
for a list of 100 elements. For my 
10-MHz AT-compatible, Nrev returned 
17,704.5—a very good performance 
figure. 

Speed is only one of the outstanding 
features of this compact compiler. Add 
a module system, tail recursion optimi¬ 
zation, garbage collection, and the abil¬ 
ity to create stand-alone executable 
applications, tie it all together with a set 
of useful program development utilities 
such as editors (the venerable Unix vi), 
a library of window routines, interfaces 
to C compilers, language extensions, 
and sample programs, and the package 
can unequivocally be labeled “Profes¬ 
sional.” 
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ALS Prolog is an interactive, 
incremental compiler. The language 
closely resembles that implemented in 
the Edinburgh Prolog or C-Prolog 
interpreters. The main difference is that 
all Prolog definitions, whether con¬ 
sulted from files (including the pseudo 
file ’userlj) or asserted, are instantane¬ 
ously compiled (resulting in the fast exe¬ 
cution mentioned earlier). Almost all of 
the facilities described in Programming 
in Prolog, 2nd edition, by Clocksin and 
Mellish (Springer-Verlag, 1984), are 
implemented in ALS Prolog. For 
instance, files are consulted and goals 
are submitted exactly as presented in the 
book. 

The machine-dependent advantages 
include the possibility of creating vir¬ 
tual code space allowing programs 
larger than available memory to run, 
graphics and windowing functions, for¬ 
eign language interfaces, and operating 
system calls. 

The interpreter is small and fast. The 
executable file—less than 100 Kbytes— 
loads quickly. It runs in harmony with 
any number of memory-resident utili¬ 
ties, which is not the case with all Pro¬ 
log compilers. The simple installation 
can be done onto floppy drives or hard 
drives. 

A keyboard enhancement program 
among the utilities on the distribution 
disk provides a bigger type-ahead 
buffer and nearly immediate recogni¬ 
tion of control-C, which allows you to 
stop runaway programs instead of 
rebooting the system. However, it slows 
the computer down and may create dif¬ 
ficulties with other keyboard enhance¬ 
ment programs. You also get some 
sample ALS Prolog programs. 

You can use command-line argu¬ 
ments; they will be consulted automati¬ 
cally. For example, the simple 
command 

C:> alspro filel file2 

will call the ALS Prolog compiler 
(which loads the built-in file) and then 
consult the files filel and file2. 

The switches are useful, too. For 
example, - v will print all system load¬ 
ing messages, including some normally 
suppressed, while -q will suppress all 
messages, including the banner. 

If you use other Prolog compilers, 
you might have to declare predicates 
that you want to assert because many of 
these Prolog compilers do not compile 
predicates that will undergo assertions; 
they leave them interpreted and call 
them dynamic predicates. In ALS Pro¬ 
log you can assert into compiled predi¬ 
cates and retract from them; therefore, 
dynamic predicates do not exist and you 
don’t have to declare them. 


You can obtain retraction of clauses 
by an advanced decompilation method. 
Recompilation also provides listings 
and calls for the debugger. I found it 
advantageous to use the ALS debugger 
because in ALS Prolog compiled code is 
debugged, not interpreted code. There¬ 
fore, the consistency problem between 
interpreted and compiled code dis¬ 
appears. 

Indexing is provided on the first argu¬ 
ment of all predicates. Assertions and 
retractions to a predicate eliminate this 
indexing, leaving only the simple 
sequential indexing of clauses for the 
procedure. During a file consult or 
reconsult, full indexing is created. 

I was pleasantly surprised by three 
important features of this Prolog; it 
provides complete garbage collection at 
the head and tail, reclaims the code 
space occupied by a clause immediately 
after it is retracted, and implements 
last-call optimization, which includes 
tail recursion optimization. Because of 
this, I can write programs that run per¬ 
petually (such as the top levels of inter¬ 
active interpreters), do a significant 
number of asserts and retracts, reverse 
lists of over 2,000 elements, or deal with 
complex and lengthy computations—a 
must for serious development. 

The ALS Prolog compiler is imple¬ 
mented using a threaded code inter¬ 
preter for an abstract Prolog machine. 
Another speed advantage is that it com¬ 
piles 16-bit integer arithmetic in-line, so 
the arithmetic comparison predicates 
will run very fast. 

If you want to hand-compile some 
clauses, you can use a built-in predicate, 
which allows access to the code genera¬ 
tor of the underlying machine. In 
general, ALS Prolog does not require 
that file names be enclosed in single 
quotes (the exceptions to this con¬ 
venience are the system built-in predi¬ 
cates ’see’ and ’tell’, both of which 
require the standard enclosing single 
quotes whenever the title name is not an 
atom). 

ALS Prolog includes an advanced 
four-port debugger, implemented in 
ALS Prolog itself. The company pro¬ 
vides the source code. You can define 
up to 14 modules in a given program. 
Multiple modules can appear in the 
same file, and a single module can be 
defined in several files. Some of the 
built-in predicates are implemented in 
assembly language, some in C, and 
many in ALS Prolog itself. 

ALS Professional Prolog can load 
and run user-written C programs (at 
this time, only Aztec C86, version 3.2, 
and the small and compact memory 
models of Microsoft C). You can write 
Prolog predicates in C, respecting cer¬ 


tain requirements. 

One of the continuing issues of devel¬ 
opment in Prolog is the lack of porta¬ 
bility among compilers. ALS tries to 
maintain the Edinburgh standard, but 
many functions are system dependent. 
Of the sample programs, only a few 
would work with other compilers (to be 
sure, very few non-ALS programs 
would run without modification in ALS 
Prolog). This difficulty results from a 
lack of standards, a deficiency I expect 
to see addressed as the language 
matures. For the present, you must 
choose one compiler and hope a stan¬ 
dard will develop. 

Another virtue of ALS Prolog and a 
credit to its writers is the documenta¬ 
tion. It consists of one succinct, well 
written, precise manual produced by 
developers for developers. 

A single copy costs $499, including 
one year of free updates. I recommend 
ALS Professional Prolog to anyone 
interested in this elegant language. Con¬ 
tact Applied Logic Systems, PO Box 90, 
University Station, Syracuse, NY 
13210, phone (315) 471-3900. 
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KnowledgePro—a knowledge 
processor for PCs 

KnowledgePro is a development and 
communication language for IBM PC, 
XT, AT, PS/2, and compatible MS- 
DOS computers with 640 Kbytes of 
RAM and a hard disk. KnowledgePro 
combines hypertext and expert systems 
in a new technique for storing and com¬ 
municating ideas and information. It 
has development and consultation capa¬ 
bilities, a symbolic (list processing) lan¬ 
guage, and direct procedural control 
(windows, access to external graphics 
and other software, and data exchange 
with spreadsheets, databases, and artifi¬ 
cial intelligence applications tools). 

The authors chose to represent 
knowledge from a communication point 
of view, that is, by communicating 
expertise directly, without predefined 
structures. They consider Knowledge- 
Pro a new kind of high-level program¬ 
ming language, with a not-too-complex 
syntax, easy to learn and use, and par¬ 
ticularly suited for artificial intelligence 
applications. The main commands are 
Say (for displaying a message), Ask (a 
question), If-Then (for rules), #m (for 
marking an item in the hypertext), Win¬ 
dow (open), Close_window, Write, 
Menu, and Edit. 

Using KnowledgePro you can manip¬ 
ulate, store, and retrieve knowledge. 
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This includes constructing expert sys¬ 
tems (using production rules and 
inference-engine capabilities) or knowl¬ 
edge bases. KnowledgePro provides 
structures to work with, like inference, 
list processing, topics, procedural con¬ 
trol, and inheritance. A useful feature 
allows you to write new procedures in 
other languages and interface to other 
programs. Using routines in the exter¬ 
nal library modules, you can access 
dBase III, PCPaint, and Lotus 1-2-3 
files. 

The hypertext links related concepts, 
logic, or procedures. Practically speak¬ 
ing, the hypertext adds a third dimen¬ 
sion to the written material, like 
manuals, help systems, procedures, pro¬ 
tocols, sales information, staff training, 
and reference works. Hypertext allows 
users to access information using this 
third dimension, jumping from a word 
or a group of words to their meaning, 
explanation, or more details. For 
instance, I can create or display a screen 
of text with certain words or a group of 
words highlighted. By pressing a func¬ 
tion key or mouse button, I can follow 
a thread to windows that explain the 
highlighted words and that might them¬ 
selves include other highlights. 

The hypertext and an expert system 
interact by having a highlighted item 
from a hypertext cause a rule to execute 
in an expert system, or by passing from 
an expert system to the third dimension 
of a hypertext through a highlighted 

You can process and organize knowl¬ 
edge in several ways with Knowledge- 
Pro: 

• hypertext (discussed above); 

• topics, which are structures (such as 
procedures, variables, functions, 
frames, commands, hypertext) with 
given names that the user can 
arrange hierarchically; it is the main 
structural unit in KnowledgePro; 

• rules (if-then-else rules for expert 
systems); and 

• direct procedural control, with 
commands to manipulate words or 
groups of words (like combine, 
first, last, intersect, and union), cre¬ 
ate windows, change window 
colors, perform calculations, read 
from and write to external files, and 
create macros and menus. 

To enter a text you can use any text 
editor or the KnowledgePro editor, 
which works within user-designed win¬ 
dows. To highlight an element, use 
at the beginning and at the end of the 
element. 

The system comes on three 360-Kbyte 
capacity diskettes labeled Programs, 
Knowledge Base Files, and Run-Time 


System. The installation, either auto¬ 
matic or manual, is very simple (it 
requires 1.2 Mbytes of space on the 
hard drive). From the opening menu 
you can choose to see some demonstra¬ 
tion knowledge bases, print some of the 
source files and follow along as they 
run, or create a knowledge base. 

KnowledgePro can call on different 
knowledge representation techniques. I 
like the fact that I can create topics 
dynamically in a KnowledgePro pro¬ 
gram and that messages can change 
dynamically, depending on information 
provided by the user. To create specially 
formatted messages, I used the Say or 
Display commands. I didn’t like the dis¬ 
play commands because they are harder 
to lay out and take longer to display 
since they must be interpreted. 

Other things about KnowledgePro I 
do not like include its failure to use 


graphics, its slowness in returning from 
the third dimension of the hypertext, 
and its inflexible windows. I did like the 
many examples included with the sys¬ 
tem and the documentation, which is 
well-written and easy to read. On-line 
documentation is also available. 

KnowledgePro can be useful to 
different kinds of users, from beginners 
to experienced programmers. For help 
you can consult a Readme file on the 
KnowledgePro diskette, telephone 
assistance, and user-support forums. 

The package costs $495 plus $8 shipping 
and handling. There are no runtime 
fees. Graphics and database toolkits are 
available as $49 add-on products. Con¬ 
tact Knowledge Garden, 473A Malden 
Bridge Rd., Nassau, NY 12123, phone 
(518) 766-3000. 
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Socrates Knowledge Base Management System 


The ancient philosopher Socrates 
(470-399 B.C.) is back in business. CIM 
Solutions applies his famous method of 
systematic questioning to find the truth 
in their knowledge base management 
system called—you guessed it—Socrates 
KBMS. 

Socrates KBMS Version 1.1 is an 
expert system generator involving a 
tree-structured, menu-driven user inter¬ 
face. It locates the solution of a prob¬ 
lem by using forward-chaining logic. 

All the commands are menu driven, and 


you can easily modify the tree structure. 
I like the fact that Socrates KBMS has 
many programming language features, 
including the ability to call other pro¬ 
grams from within the tree structure. 

According to CIM, Socrates KBMS 
helps diagnose and solve practical busi¬ 
ness and technical problems. It runs on 
VAX computers and the IBM PC or 
compatible with at least 256 Kbytes of 
RAM and DOS V2.0 or higher. In this 
interactive technical support tool, users 
are prompted to solve their problems in 




Authoring program 

(Used in creating the 
knowledge base, allowing 
creation of the tree structure) 

Query program 

(Read only, and intended 
only forgiving help) 

Soci 

KB 

•ates 

MS 1- 





Management program 

(Allows the manager to 
search for unsolved problems) 


Figure 1. Socrates KBMS contains three separate programs, as shown here. 
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a Socratic manner. The program pro¬ 
vides the framework to create a custom- 
tailored expert system. Practically 
speaking, Socrates KBMS asks the user 
a series of questions and, based on the 
answers, gives a solution. 

Built on a decision tree structure, the 
expert knowledge initially needs to be 
input into Socrates KBMS. You start 
with a general problem and break it 
down into smaller topics with their 
respective solutions. These solutions 
can be text files, graphics files, or both. 
After you have entered the knowledge 
into Socrates KBMS, any user can 
access that information by starting with 
a general problem and selecting the 
menu choice that relates to his or her 
particular situation. Each menu choice 
brings to the screen a new list of prob¬ 
lem identifications relating to that spe¬ 
cific choice. By following the problem 
from general to particular, the user will 
find the solution previously input. 

Socrates KBMS contains three sepa¬ 
rate programs, as shown in Figure 1. It 
manages knowledge by categorizing, 
searching, and retaining knowledge 
from the expert user. 

Socrates KBMS has several built-in 
features for easy use by both the expert 


(who inputs the knowledge) and the 
user (who needs the solution). Figure 2 
presents some of these features. 

The installation is very simple, with 
only one diskette to load. The manual is 
small and easy to read. 

Socrates KBMS is a practical tool for 
developing simple expert systems. 

Prices start at $295 for a single-user 
program running on a DOS-based PC. 
Contact CIM Solutions, 2696 N. Uni¬ 
versity Ave., Suite #280, Provo, UT 
84604, phone (801) 374-5626. 
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Summing up 

I believe that artificial intelligence is 
the future of the computer industry and 
that successful companies and people 
will be those that effectively utilize its 
techniques. In fact, nearly every day we 
can find a new AI application to meet 
our immediate and practical computer 
needs. AI has taken an increasing mar¬ 
ket share of the computer industry, and 
products like those described here show 
clearly why this is happening. 


Product notes 

• Looking for a way to add more 
memory to your AT or 386? Newer 
Technology offers Attention! 2 , a 
memory board available with 
256-Kbit or 1-Mbit RAM chip con¬ 
figurations (or as bare boards) and 
total extended or expanded memory 
up to 16 Mbytes (with an optional 
daughter board). To go to 32 
Mbytes, look at the Concentration 
memory board. Newer Technology, 
1117 S. Rock Rd., Suite 4, Wichita, 
KS 62707, phone (316) 685-4904. 

• IGC has announced the release of 
VM/386 Multiuser, a new program 
that lets one 386 PC act as a host for 
up to eight PC-compatible terminals. 
386 PCs and attached terminals run¬ 
ning under VM/386 Multiuser can 
be connected to a network and 
access the network data and applica¬ 
tions without the cost of another file 
server or additional connections. 
Suggested list price is $895. Also, 
release 1.2 of VM/386 is available 
and offers disk partitions larger than 
32 Mbytes under DOS 4.0 (or Com¬ 
paq DOS 3.31), 3COM network sup¬ 
port, printer sharing among virtual 
machines, faster switching between 
virtual machines, and lower CPU 
overhead to run VM/386. Available 
from IGC, 4800 Great American 
Parkway, Santa Clara, CA 95054, 
phone (408) 986-8373. This excellent 
386 virtual machine monitor, 
reviewed in the August 1988 issue, 
was highly recommended. 

• MetraByte’s RTM-1000 data 
acquisition and control software 
package allows IBM PC users to 
receive, display, and log data from 
the MetraBus system of industrial 
control and monitoring interface 
boards. Operating in a fore¬ 
ground/background mode, the soft¬ 
ware performs process control in the 
background, allowing the user to 
perform a variety of tasks in the 
foreground. Priced at $995, the 
package is available from Metra- 
Byte, 440 Myles Standish Blvd., 
Taunton, MA 02780, phone (508) 
880-3000. 

• Digital Research announced 
X/GEM, a graphics software exten¬ 
sion to DOS that provides graphics 
capability to protected-mode, real¬ 
time, multitasking, multiuser operat¬ 
ing systems or networked environ¬ 
ments. First implementations will be 
on DRI’s FlexOS 286 and 386 real¬ 
time operating systems. DRI can be 
reached at Box DRI, Monterey, CA 
93942, phone (408) 649-3896. 


Search 

(To search through the 
entire structure for a 
key word) 


Transfer 

(To exit from Socrates KBMS 
and enter another program) 


Go-to statement 


(To jump from any branch of 
the tree to any other branch) 


Menus 

(For easy use by 
nonprogrammers) 


Figure 2. Socrates KBMS has several built-in features for easy use by the expert, 
who inputs the knowledge, and the user, who needs the solution. Some of the fea¬ 
tures are shown here. 
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Ada programmers are made, not hired 


T.L. (Frank) Pappas, Intermetrics 

Finding good Ada programmers is 
difficult. The few who exist are hard to 
pry away from other companies. So 
what do you do if you’re starting an 
Ada project and don’t have any Ada 
programmers? Look around at the 
programmers you already have. Many 
of them are potential Ada 
programmers. 

In this issue, I’m fulfilling the prom¬ 
ise I made in the September issue to 
review two computer-aided instruction 
courses that you can use to teach Ada 
to programmers. The two courses com¬ 
plement each other. The first one 
teaches coding in Ada, while the second 
teaches designing in Ada. 


A context for the CAI 
courses 

Before reviewing the two products, 
it’s important that I establish the con¬ 
text in which you should use these 
courses. You can’t start an Ada project 
with a group of programmers, throw 
these CAI courses at them for a few 
weeks, and get a group of quality Ada 
programmers. It just doesn’t work that 
way. It’s not a reflection on the courses. 
The same holds true if you hire an 
instructor to come in and teach an Ada 
course. 

Lots of people seem to have trouble 
accepting that it takes a while for 
programmers to become effective in 
Ada. This is a painful lesson that each 
organization/project seems intent on 
inflicting on itself. Some people expect 
to pick up a book on Ada programming 
and become proficient in the language, 
much the way people have done with 
Pascal, C, etc. But it just doesn’t hap¬ 
pen that way with Ada. 

In exchange for allowing program¬ 
mers to build the quality software that 
Ada was designed for, the language 
demands a great deal from program¬ 
mers. Even good programmers need 
some time to adjust to the language. 
Moreover, programmers with lesser 
programming skills will have a great 
deal of difficulty adapting—if they ever 
do—to Ada. 

The best way to approach Ada educa¬ 
tion is to bring someone in to teach Ada 
courses and, depending on the back¬ 
ground of your programmers, possibly 
some software engineering courses. You 
would use the CAI courses for follow¬ 
up education, to review topics and pos¬ 


sibly get a different slant on them. The 
education should take place well before 
the project starts, so that your program¬ 
mers have lots of time to get familiar 
with the language. 

For most organizations, this 
approach isn’t feasible. For some, the 
cost involved in educating a large num¬ 
ber of people using outside instructors 
is prohibitive. For others, some of the 
key people can’t afford to leave their 
current projects that long. The two CAI 
courses are really useful in such situa¬ 
tions, especially if you have a few peo¬ 
ple, already well-versed in Ada, who 
can answer Ada questions. 

You can start by educating a core 
group, letting them progress as their 
schedules allow. This lets them get 
familiar with the language well before 
they need to use it. Typically, this group 
would include most of your top-notch 
people—those typically involved in 
requirements and design. 

Programmers targeted for a future 
Ada project can also begin using the 
CAI courses. This gives them some 
practical coding experience, as well as 
allowing them to understand why cer¬ 
tain design issues were resolved in a par¬ 
ticular way. 

Another way to get programmers 
familiar with Ada is by letting them use 
the CAI courses during working hours, 
funding their efforts the same way you 
might a professional development 
course. If you can’t afford that, you 
might encourage some of your 
programmers to use the CAI courses on 
their own time in exchange for the first 
crack at plum assignments on future 
Ada projects. 

The two CAI courses reviewed below 
provide you with the flexibility you 
need to follow any of the approaches 
suggested above. You just need to make 
the first move. As the people at Alsys 
say, “Ada programmers are made, not 
hired.” 


Learning Ada 

Lessons on Ada (LOA) from Alsys is 
a good CAI course for introducing 
programmers to Ada. It has modest sys¬ 
tem requirements. It runs on an IBM 
PC, PC-XT, PC-AT, or compatible. It 
only requires 256 Kbytes of memory, 
DOS 2.0 or higher, two 5X-inch floppy 
drives, or one floppy and one hard 
drive. While it only needs one 
monitor—monochrome or color—it can 


make good use of two, as described 
below. The system is also available on 
other systems, such as VAX VMS and 
Sun and Apollo workstations. 

LOA also requires a parallel printer 
port to plug in one of the six 
actuators—-hardware locks—that come 
with the package. The actuator must be 
on the printer port while you use the 
course, otherwise the session will 
abruptly terminate. This prevents you 
from making unauthorized copies of 
the CAI, or at least from using more 
than six at a time. 

The system costs $6,000. A set of 
complimentary demonstration diskettes 
is available. 

LOA consists of 27 well-thought-out 
lessons. Each lesson is divided into 
topics and subtopics. As you go 
through, you can interrupt a lesson and 
return to it later. When you do return 
to it, you have the option of beginning 
at the start of the lesson or at the start 
of the subtopic. It would be nice if you 
could start again at the exact slide you 
were viewing when you stopped. I 
found it a bit annoying to have to start 
the subtopic over again, but since the 
subtopics are fairly short, it’s tolerable. 
This should be an enhancement. 

Within a lesson, three types of simple 
exercises test your understanding of the 
topics. One type consists of multiple 
choice and true or false questions. A 
second type asks you to place the cursor 
on a piece of program text to show 
where something is or occurs. A third 
type asks you to write a fragment of 
program text. The program text is 
“evaluated” to see if you gave a 
“reasonable” response. Of course, it’s 
just looking for some key features in 
the fragments. Although not perfect, it 
is very effective. 

LOA assumes two logical screens. If 
you have two monitors, each logical 
screen is mapped to its own monitor. 
Otherwise, a flashing symbol in the 
upper left-hand corner tells you when to 
bring up the other screen (accomplished 
with a single keystroke). The primary 
screen presents the text material. The 
other screen presents examples and ani¬ 
mation. I used a single monitor and had 
no problem switching screens, but if 
you can use two monitors, LOA would 
be even more effective. 

I’d like to see an enhancement to 
make reviewing a lesson easier. Right 
now, there’s no nice way to get past an 
exercise if you just want to review a les¬ 
son. If you enter a null response three 
times, LOA will give you the correct 
answer. It would be nice to have a func¬ 
tion key that would let you skip over a 
particular exercise, or one that would 
let you enter a review-only mode. This 
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would make LOA even better. 

The lessons do a good job of explain¬ 
ing Ada’s features. For example, two 
lessons cover exception handling— 
Ada’s method for dealing with excep¬ 
tional situations. One lesson thoroughly 
introduces the basics of exception han¬ 
dling in sequential Ada programming. 
The lessons on tasking deal with excep¬ 
tion handling in concurrent program¬ 
ming. A second lesson, devoted to 
programming with exceptions, does a 
very nice job of explaining when you 
should use exceptions. 

As another example, the lesson on 
separate compilation also discusses 
elaboration in detail. Elaboration is the 
process by which Ada declarations 
achieve their effect (allocate storage, 
assign initial values, etc.). Many 
programmers have trouble with this 
concept when it’s first introduced to 
them. LOA does a nice job of explain¬ 
ing it. Elaboration, already introduced 
as needed earlier in the lessons, is 
reviewed in the separate compilation 
lesson. Then elaboration is extended to 
program units. Finally, elaboration 
order is contrasted with compilation 
order. This makes the presentation of 
elaboration very effective. 

The only major complaint I have with 
LOA is the use of an actuator. I find 
actuators annoying. Many companies 
feel they need to protect PC software by 
using them, so Alsys is not alone. But if 
your system has several products that 
require an actuator, you might have 
problems if you keep the back of your 
PC close to a wall like 1 do. Even if 
space isn’t a problem, I don’t believe 
that there won’t be some conflicts 
between actuators. 

Even though 1 really dislike the fact 
that Alsys requires an actuator, I 
wouldn’t let it keep me from getting 
LOA. The product is much too good to 
pass up. But 1 probably would avoid a 
lesser product. 

Even with the few nits 1 have with 
LOA, I think it’s a good CAI course. 
You should make it part of your Ada 
education program. Contact Alsys, 

1432 Main St., Waltham, MA 02154, 
phone (617) 890-0030. 
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Learning to design in Ada 

The AIS-11 Ada Software Develop¬ 
ment Curriculum from McDonnell 
Douglas consists of three CAI courses. 
They can be used under VAX/VMS or 
under MS-DOS (3.1 or later). 

The MS-DOS version is tailored to 
either Alsys’ Ada compiler or Merid¬ 


ian’s AdaVantage compiler. If you use 
Meridian’s compiler, you need an IBM 
PC-XT or compatible with an 8087 
coprocessor and a 360-Kbyte floppy 
drive. If you use Alsys’ compiler, you 
need an IBM PC-AT or compatible 
with an 80287 coprocessor or a Com¬ 
paq 386 or compatible with an 80287 
or 80387 coprocessor; both require a 
1.2-Mbyte floppy drive. For either com¬ 
piler you also need 640 Kbytes of mem¬ 
ory, EGA and (preferably color) 
monitor, and a hard disk drive. You’ll 
need a printer with 132-column capabil¬ 
ity (actual or compressed) if you want 
to print out statistics about the courses 
and students. A mouse is also recom¬ 
mended, but not required. 

To use the Alsys compiler, you’ll 
need an expansion slot to plug in a 
4-Mbyte memory board. Alsys supplies 
the memory board with the AT version, 
but not with the 386 version. AIS-II 
comes with the Meridian compiler. The 
actual courseware is shipped on a 
40-Mbyte “hardcard,” so you also need 
an 8-bit expansion slot to plug in the 
card. 

I used Zenith’s MS-DOS 3.2 on a 
Heath H-386, with the Alsys compiler, 
an 80287 coprocessor, VGA graphics, 
Zenith’s flat-screen color monitor, and 
Mouse System Technologies’ PC 
Mouse. 

The three courses (with PC prices) are 

• Software Development: DoD 2167 
Life Cycle ($4,600), 

• Ada in Software Design ($7,700), 
and 

• Managing Ada Software Develop¬ 
ment ($1,900). 

If you buy all three courses, you can get 
them at the discounted price of $12,000. 
Leasing is available, and you can apply 
the leasing costs to the purchase price if 
you decide to buy. And, of course, 
there are volume discounts. 

The most I can do in the rest of this 
review is provide a small sampling of 
the quality of this courseware. You 
really need to sit down and use it to 
appreciate it. For example, you need to 
see how graphics and color are put to 
really good use, or how well the student 
handouts match the lessons. A set of 
complimentary courseware demonstra¬ 
tion disks available from McDonnell 
Douglas includes four sample lessons 
and the associated student handouts. I 
think the sample disks will convince 
you. 

The AIS-II courseware was developed 
in-house for training at McDonnell 
Douglas, so it’s well tested. Because the 
company specializes in aerospace, the 
examples naturally deal with embedded 
real-time systems. There are pros and 


Some useful Ada textbooks 


The three books listed below are 
good supplements to the CAI 
courses. Each satisfies a slightly 
different need. 

Programming in Ada by J. Barnes 
(Addison-Wesley Publishing Co., 
Reading, Mass.) 

This book is a good introductory text 
on Ada and has become somewhat 
of a standard. It covers the major fea¬ 
tures of the language. 

Ada as a Second Language by N. 
Cohen (McGraw-Hill Book Co., 
Hightstown, N.J.) 

This book provides advanced, 
detailed coverage of Ada for 
programmers familiar with Fortran, 
PL/I, or Pascal. I consider it an excel¬ 
lent reference book for all Ada 
programmers. It has more than 800 
pages of text and examples. I recom¬ 
mend it as an introductory text for 
self-motivated programmers. 

Software Development with Ada by 
I. Sommerville and R. Morrison 
(Addison-Wesley Publishing Co., 
Reading, Mass.) 

This book looks at the design of 
electronic-mail systems in Ada. 
Object-oriented programming, func¬ 
tional decomposition, and dataflow 
analysis are used in the design. 


cons to this. The courseware deals with 
most of the Ada issues you will ever 
face, but if you work in a strictly com¬ 
mercial world, you might encounter 
issues that you normally wouldn’t have 
to worry about. 

Throughout, the course asks students 
questions to help reinforce the material 
they are learning. Progress checks are 
also included. You can ask to review 
what you have seen so far in the lesson. 
Each lesson ends with a mastery test. 
You can break at any point in a lesson 
and start up again exactly where you 
left off. 

The AIS-II courseware is under the 
control of a systems administrator. The 
SA must register students before they 
can take the courses. AIS-II keeps 
statistics about each student’s progress 
and about each course. The SA can 
print the statistics in one of several use¬ 
ful report formats. 

A student must pass one lesson 
before moving on to the next. If you 
fail a lesson (the mastery test), you must 
go through it again. If you fail it again, 
you can’t go on to the next lesson with¬ 
out action from the SA. This means 
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Where do you find good 
Ada programmers? 





AtejsMaNw: 


Free 

Poster offer: 
see coupon. 


You could spend and spend 
trying to hire good Ada programmers 
and still not find what you need. Big 
demand; short supply. The irony 
is, your best Ada people may be the 
programmers you already have; all 
they need is good training. 

Alsys offers a full range of quality 
Ada training products for growing your 
own programmers. For example... 

■ A 27 video tape seminar covering 
the entire Ada language-18 hours 
of authoritative instruction by the 
principal designer of the language 
itself. Benefit? Understanding Ada’s 
architecture and scope should be 

the foundation for all further work or 
study. It will help develop that most 
elusive skill: the Ada programming 
intuition to guess right. 

■ For programmers ready for 
hands-on skills development, a 
comprehensive CAI course on a PC, 
running 50-60 hours, with exer¬ 
cises and progress tracking. Multiple 


users. Licenses for 5 machines. The 
course is also excellent for brushing 
up, or extra work on one subject, or 
for new employees. 

■ For practicing, and then moving 
directly to serious Ada programming, 
Alsys offers a full-featured, production 
quality Ada compiler, with tools, 
for the PC AT. This same compiler is 
used to build some of the largest Ada 
programs in 
existence! 

Alsys offers 
more training 
products. A 
CAI course for 
programmers 
familiar with 
Fortran... 
a searchable, 
on-line version 
of the Reference 
Manual... 
a (limited) 
offering of live 
training courses. 


Good Ada training for your own 
people. For Ada now. Write or call. 

vImi/w 

Ada Programmers 
Are Made - Not Hired. 


In the US: Alsys Inc., 1432 Main St., Waltham. MA 02154161: (617) 890-0030 

In the UK: Alsys Ltd., Partridge House, Newtown Rd„ Henley-on-Thames, Oxon RG91EN Tfel: 44 (491) 579090 
In the rest of the world: Alsys SA, 29 Avenue de Versailles, 78170 La Celle St„ Cloud, France Tfel: 33 (1) 3918.12.44 


r* 


Send me POSTER and more information on: 

Ichbiah, Barnes & Firth on Ada 27-tape Video Series. 

_ Lessons on Ada CAI Course. _Live Training. 

_ PC AT Compiler and Tools. _ AdaQuery On-Line Reference. 

_ You Know Fortran, Ada is Simple CAI Course. 

_ Ada Immersion Combination Package. 

Name_ 

Company_ 

Address_ 

City_State_Zip_ 

Phone ( )_Ext_ 

Mail to: Alsys, Inc. 1432 Main St., Waltham, MA 02154 
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that any problems a student has with a 
topic can be straightened out during 
training, rather than during a project. 
The SA can also register a student for 
audit only, in which case the lessons are 
taken pass/fail in any order. 

The only deficiency I found is that 
you can’t bypass quizzes or tests, even 
if you’re only reviewing or auditing the 
lesson. With the amount of material 
presented in the courseware, I think you 
need some way of reviewing. Once you 
have passed a lesson, or if you are 
auditing the course, you should be 
allowed to bypass any quiz or test. 

Anyway, let me give you an overview 
of the courses. The first one, as its 
name implies, concerns DoD 2167. It 
takes about 14 hours to go through the 
17 lessons. The intended audience is 
programming personnel unfamiliar with 
2167 and/or its impact on Ada projects. 
The course covers 2167 in detail and 
shows how Ada’s strengths relate to the 
stages of the 2167 life cycle. The only 
prerequisite is experience in some pro¬ 
gramming language. This is the one 
course that you can skip in a strictly 


commercial environment. 

The second course concerns design. It 
consists of six blocks of instruction and 
29 lessons. It requires 37 hours of CAI 
instruction and 25 hours of Ada pro¬ 
gramming. The intended audience is 
software designers, programmers, and 
(technical) managers. This is the only 
one of the three courses that requires a 
compiler. It has a really nice interface 
into the Ada programming environ¬ 
ment. When you get a programming 
assignment, you can invoke an editor 
(which you must install with the course¬ 
ware) and the Ada compiler right from 
AIS-II. When you finish the assign¬ 
ment, the program gives you feedback 
on your solution and presents a sample 
solution. 

The design course uses an ongoing 
example of developing an embedded 
inertial guidance system. The example is 
presented in enough detail so that even 
if you don’t know what an inertial gui¬ 
dance system is, you will still get a lot 
out of the example. The prerequisite for 
this course is an understanding of the 
basic features of Ada. (Alsys’ Lessons 


Erziehungsdepartement/Universitat 


University of Basel, Switzerland 
Department of Computer Science 

Applications are invited for the position of 

PROFESSOR OF COMPUTER SCIENCE 

Candidates should have a Ph.D. Degree, demonstrated 
teaching ability and research interests in at least two of the 
following fields: man-machine interaction, end user 
computing, information retrieval, multi media communication, 
computer assisted learning. Responsibilities include teaching 
computer science and data processing to undergraduates 
from other faculties and the participation in the administrative 
duties of the department. 

The School awards Master and Doctoral Degrees. The 
language of instruction is German. 

Applications with professional resume (vita, degrees, 
working experience, publications) and the name of three 
references should be submitted to: (until Jan. 31,1989). No 
visa-problems are expected. 

Erziehungsdepartement BASEL-Stadt 
Personalsekretariat I (URZ I.f.I) 

Miinsterplatz 2 
CH-4001 Basel 


on Ada will do a really good job of 
preparing you for this course.) 

The final course concerns managing 
an Ada development effort. It consists 
of five lessons and only takes about five 
hours to complete. The target audience 
is project and software-development 
managers. The 2167 course is a sug¬ 
gested prerequisite. The course dis¬ 
cusses issues such as benchmarking, 
compiler and tool acquisition, runtime 
systems, training, staffing, and schedul¬ 
ing in the context of an ongoing 
example. 

The course places the student in the 
role of a project manager who must 
staff up and tool up an Ada project. 

The project is an embedded missile 
flight system, a simulation and test 
facility for the system, and a data anal¬ 
ysis capability for analyzing the data 
generated by the simulation. The proj¬ 
ect assumes that the embedded flight 
system will use a 1750-A processor with 
a 16-hertz cycle. The system must fit in 
64 Kbytes and have a 75-percent duty 
cycle. To make the example even more 
realistic, the system must be nuclear 
certified—the software can’t be 
accidentally or intentionally corrupted. 

Throughout the courses, the lesson 
titles accurately represent the material 
presented. One title looks a bit strange: 

‘ ‘Acquiring an appropriate toolset and 
obtaining nuclear certification.” That’s 
a little like the First National Bar, 

Bank, and Grill. But for someone audit¬ 
ing the course, the titles allow picking 
and choosing. 

If you get the AIS-II courseware, I 
think you’ll be pleased with it. Using it 
before your Ada project starts will help 
you avoid a great deal of pain. Contact 
McDonnell Douglas, Computer-Based 
Training Systems, 2450 S. Peoria St., 
Suite 400, Aurora, CO 80014, phone 
(303) 671-4800. For demonstration 
disks, mention Dept. SA-2. 
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Summing up 

If you need to educate people about 
Ada, you need Lessons on Ada and 
AIS-II. I have taught several Ada 
courses, and if I had to teach an Ada 
course again, I would want to use these 
courses for most of the instruction. It 
makes it easier on the students and the 
instructors and lets students progress at 
their own rates. The time, effort, and 
cost involved in using these courses will 
prove worthwhile when work on your 
Ada project begins. 
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GET ON TH E “ PAWS" EXPRESSWAY’ 


Why nor take rhe shorresr and fastest route 
toward system design solutions? To define 
and model a large, complex system, you 
need a modeling tool that con address rhe 
system's total architecture. 

00 PAWS/GPSM™ is on easy-to-use high 
ft f productivity modeling and simulation 
Jh* tool that lets you evaluate alternative 
architectures while focusing on performance. 
It provides a state-of-the-art environment for 
developing accurate and reliable product 
definitions. 

00 PAWS provides high level primitives 
t <| closely resembling the user's intuition. 

PAWS models the behavior of a total 
system implemented in diverse technologies 
including software, hardware, and firmware. 


GPSM, the graphical interface to 
PAWS, helps you quickly and easily 
transfer your ideas into pictures. GPSM 
helps you visualize multiple data and control 
flows through several components and 
incrementally synthesize models of o total 
system. 

0 0 PAWS/GPSM is flexible. It lets you refine 
fk your model as your system design 
Mtk, evolves so you con eliminate potential 
problems os early as possible in rhe product 
design cycle. 

Call (512) 474-4526 to receive information 
on PAWS/GPSM. And get on the PAWS 
expressway to system design solutions. 

P/UVS and GPSM are trademarks of Information Research Associates, Inc. 


Information Research Associates • 911 W. 29th St. • Austin, Texas 78705 • ( 512 ) 474-4526 
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NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail+, n.t 


Bravo3 CAD/CAM line moves to Mac II 
as MacBravo! 


Schlumberger CAD/CAM has 
adapted its Bravo3 products for the 
Apple Macintosh II. The first two 
products in the MacBravo! family are 
the Modeler and the Detailer. The 
Modeler is reportedly task optimized 
for 3D mechanical design. The Detailer 
is a mechanical drafting software pack¬ 
age supposedly optimized for engineer¬ 
ing, manufacturing, and government 
drawings. 

According to the company, Mac¬ 
Bravo! products contain a customiza¬ 
tion capability called the Flexible 
Interface Tool. FIT permits users to 
change the interface, invent a new one, 
develop new options and commands or 
delete existing ones, or write new 
programs. 

The company plans to offer other 


Myrias Computer claims that its Scal¬ 
able Parallel Supercomputer (SPS-2) 
has an automatic programming envi¬ 
ronment. The SPS-2 features the com¬ 
pany’s Parallel Application 
Management System, or PAMS, which 
reportedly distributes work automati¬ 
cally during execution. 

According to the company, applica¬ 
tions are developed in a Unix environ¬ 
ment. Adding the parallel control 
statement “pardo” allows programmers 
to express parallelism in the application 
through Fortran and C. 

The SPS-2 uses Motorola 68020 
processors with 4 Mbytes of memory 
each. Configurations range from 64 to 
1,024 processors. The 256-Mbyte to 
4-Gbyte distributed memory is global. 
The memory model provides global vir¬ 
tual memory to all of the processors. 

Prices start at $750,000 for a 
64-processor system with 256 Mbytes of 
memory. Deliveries are scheduled for 
the first quarter of 1989. 
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Bravo3 products on the Macintosh II, 
including mechanical CAD and CAM 
products. The MacBravo! applications 
can share information with each other 
and with Bravo3 applications running 
on VAX or Sun platforms. They 
also support IGES, DXF, and PICT. 

MacBravo! applications are sched¬ 
uled for availability during the first 
quarter of 1989 through value-added 
resellers. Prices for the products pur¬ 
chased separately are $1,495 for the 
Modeler, $1,995 for the Detailer, and 
$495 for IGES. All three programs 
when purchased together in the Design 
package cost $3,295. Service, including 
updates and telephone support, is $495 
per year. 
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Myrias Computer’s SPS-2 parallel 
processor relies upon the company’s 
PAMS to provide a Fortran and C envi¬ 
ronment with automatic parallelism, 
scalability, and program debugging. 


Litton automates 
engineering and design 

Litton Industrial Automation offers a 
computer-aided engineering and design 
software system for product engineering 
and design functions in discrete manu¬ 
facturing environments. 

According to the company, the sys¬ 
tem uses defined parameters, standard 
design rules, and engineering algorithms 
to organize and automate engineering 
drawings, provide computerized design 
rule checking, automate design file cre¬ 
ation, and automate bill of material 
creation. 

The software operates in a DEC VAX 
environment with a VMS operating sys¬ 
tem. It uses Intergraph workstations 
and graphics software. Contact the 
company for pricing. 
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iPSC/2 gets concurrent I/O 
and file system 

Intel has announced the Concurrent 
I/O facility and the Concurrent File 
System for the iPSC/2 supercomputer. 

Concurrent I/O hardware consists of 
80386-based I/O processing nodes con¬ 
nected to the iPSC/2 through the 
Direct-Connect message-routing net¬ 
work. The maximum iPSC/2 configura¬ 
tion is 128 nodes. The I/O system 
features Multibus II and VME- 
compatible interfaces. 

According to the company, the Con¬ 
current File System allows each node 
program to see a single virtual disk even 
when using multiple disks shared with 
other nodes. CFS reportedly divides 
files into blocks distributed among 
available disks and I/O nodes. It sup¬ 
ports parallel access from multiple I/O 
nodes to multiple disks, uses parallel 
disk caching, and uses Direct-Connect 
hardware for data transfer of 4-Kbyte 
file blocks. CFS’s file directory and 
naming conventions follow Unix’s hier¬ 
archical style. 

The iPSC/2 Concurrent I/O, avail¬ 
able now, costs $60,800 and up. CFS 
software comes bundled with CIO. 
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Myrias claims automatic programming environment for 
its SPS-2 parallel processor 
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Honeywell Bull launches flagship mainframe 


Honeywell Bull has announced the 
DPS 9000 system, which the company 
calls the flagship of its mainframe com¬ 
puter family. The new mainframe 
reputedly performs more than 1,000 
transactions per second, based on the 
TP1 debit/credit benchmark, and 17.5 
Mflops per processor, based on a Lin- 
pack benchmark. 

The DPS 9000 features an integrated 
vector processor, a multilevel cache 
architecture, the company’s GCOS 8 
operating system, OSI networking stan¬ 
dards, and TP-8 transaction processing 
software. It also has a diagnostic 
processor and duplication of major sys¬ 
tem modules in three models, according 


to the company. NEC developed the 
basic hardware, and Honeywell Bull 
created extensions to it. Groupe Bull 
developed some of the peripherals and 
the networking software. 

The DPS 9000, scheduled for delivery 
in May 1989, will be available in four 
configurations: the single-processor 
DPS 9000/91, the dual-processor DPS 
9000/92T, the triple-processor DPS 
9000/93, and the four-processor DPS 
9000/94. 

Prices will range from $5.8 million 
for a single-processor system to $22.9 
million for a multiprocessor system. 


New computer tops Concurrent line 


Concurrent Computer has topped its 
line of computers with the Model 3280E 
MPS. The new system reputedly sup¬ 
ports up to 12 processors delivering 
from 12-76.8 MIPS of performance and 
20-120 Mbytes/s of I/O throughput. It 
can directly address up to 256 Mbytes 
of memory. 

The company says that the Model 
3280E MPS has a 15-^s response time to 
high-priority interrupts. The system 
runs under Concurrent’s OS/32 operat¬ 
ing system and supports the company’s 
Fortran VII compilers, its C3Ada lan¬ 
guage system, Cobol, C, Pascal, and 
the company’s Reliance Plus relational 
database management system. 

Prices for the Model 3280E MPS 


Unix system built around 386 

Point 4 Data has announced the 
Mark 386, a multiuser system based on 
the 80386 microprocessor. The new 
computer runs the Unix operating 
system. 

The Mark 386 uses a 20-MHz 80386 
chip with zero wait states and 2-4 
Mbytes of RAM. The entry-level Model 
20 includes an 85-Mbyte ST-506 disk 
drive, a 1.2-Mbyte floppy disk drive, a 
150-Mbyte streaming tape drive, and 2 
Mbytes of memory. The base configu¬ 
ration also comes with two serial ports, 
a parallel port, and an optional mono¬ 
chrome monitor and AT-style 
keyboard. 

The Model 40 replaces the ST-506 
drive with a 170-Mbyte ESDI disk 
drive. The Model 60 has a 382-Mbyte 
ESDI disk drive. 

The Mark 386 uses Santa Cruz Oper¬ 
ation’s Xenix System V.2.3. The corn- 


start at $360,000 for two processors, 16 
Mbytes of memory, and 20 Mbytes/s of 
direct memory access. A fully config¬ 
ured system (76.8 MIPS, 256 Mbytes 
of memory) costs about $1.8 million. 

Expansion processors providing an 
additional 6.4 MIPS each cost $90,000 
without bus interface. A two-processor 
expansion package with bus interface 
hardware costs $200,000. 

Software and I/O subsystem com¬ 
patibility provide upward migration for 
lower-end Concurrent Series 3200 sys¬ 
tems. An upgrade from the Model 3280 
to the 3280E MPS consists of a bus 
upgrade to the new E-bus for $125,000. 
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Point 4’s Mark 386 relies on the 80386 
chip and runs SCO Xenix. 


pany optionally includes SCO VP/ix, 
an operating system extension that 
allows DOS applications to run concur¬ 
rently with Xenix applications. 

Prices range from $9,450 to $11,750. 
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Premise has desktop MCAE 

Premise has announced DesignView, 
a mechanical computer-aided engineer¬ 
ing software package. The MCAE 
package runs under Microsoft Windows 
on personal computers. It combines 
graphics, an integrated equation solver, 
and dimension-driven variational geom¬ 
etry, according to the company. When 
the designer changes a dimension, the 
progiam reshapes the design while 
maintaining geometric constraints and 
constrained dimensions. 

Engineers sketch a model’s geometry 
on a graphics worksheet and add con¬ 
straints and engineering calculations. 
Constraints can be geometric, dimen¬ 
sional, or equation driven. Equations 
can be used anywhere on the worksheet; 
any changes in the equations are 
reflected in the design. 

DesignView reportedly allows users 
to store text, drawings, and equations 
on a sketch and paste a design into a 
word processing program for final 
engineering reports. 

DesignView is scheduled for avail¬ 
ability in the first quarter of 1989. It 
runs on the IBM PC-AT, PS/2, and 
compatibles; requires 640 Kbytes of 
internal memory, a hard drive, a 
mouse, and a graphics card; and comes 
with a runtime version of Windows. It 
costs $1,895. Support is free for the 
first 90 days. 
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Common X Interface bridges 
Unix, PC worlds 

Hewlett-Packard and Microsoft have 
jointly announced the Common X 
Interface (CXI) graphical user interface 
for Unix operating systems. CXI 
reportedly looks and acts like MS-DOS 
computers with Microsoft Windows 
and Microsoft OS/2 with Presentation 
Manager. 

CXI is based on the X Window Sys¬ 
tem. It consists of three basic compo¬ 
nents: a style guide, the HP X Widget 
application programming interface 
specification and software, and the HP 
Window Manager. 

CXI source code will be available 
through technology licensing. The style 
guide and application programming 
interface software are available now. A 
window manager, needed to run appli¬ 
cations, will be available in the second 
quarter of 1989. 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


ACC Microelectronics 

ACC-82300 

Chip set 

ACC Microelectronics 

ACC-85000 

Chip set 

Advanced Micro Devices 
Am29C327 

Floating-point processor 


A three-device chip set for building 20-MHz 80386-based IBM PC-AT compatible com¬ 
puters. Consists of the ACC-2500 system controller, ACC-2300 memory controller, and 
ACC-2000 peripheral controller. Cost: starts at $100. 

A four-device chip set for building computers compatible with IBM’s PS/2 Model 50, 50Z, 
and 60. Operates at up to 20 MHz in turbo mode; 10 MHz in normal mode. Includes sup¬ 
port for page-interleave access of memory. Has EMS hardware and operates with the 
80386SX CPU. Cost: starts at $160. 

A 64-bit, double-precision, floating-point processor that complies with IEEE 754. Features 
floating-point and integer instructions, user-selectable pipelining, single-instruction 
multiply-accumulate, and handling of denormalized numbers. Has a 125- or 100-ns 
throughput rate. Comes in a 169-pin PGA. Cost (100s): $399 (125 ns) and $599 (100 ns). 


Advanced Micro Devices 

Am99C10 

CAM 


Intel 

27C202, 27C203 
EPROMs 


A VLSI content-addressable memory with a capacity of 256 words and a user- 
programmable word width of 16 bits or 48 bits. Each word consists of a 48-bit register and 
a 48-bit maskable comparator. The CAM comes in a 28-pin 400-mil ceramic DIP. Cost 
(100s): $42.50. 

Two 256-Kbit CHMOS EPROMs with specialized processor bus interfaces. Organized 
16K x 16. The 27C203 supports clock rates up to 20 MHz with zero wait states. The 27C202 
optimizes burst access modes of 32-bit embedded processors. Both come in 40-pin ceramic 
DIPs and 44-lead cerquads. Cost (5,000s): 27C202—$40 (70V05) or $36 (90V05); 

27C203—$35 (55V05) or $42 (45V05). 


Intel 

82311 

MCA chip set 


Implements an Intel 386-based Micro Channel architecture in 98 chips. Runs at speeds up 125 
to 25 MHz and works with the 16-MHz 386SX. Consists of 82303/304, 82307 DMA con¬ 
troller, 82308 bus controller, 82309 address bus controller, 32077 floppy disk controller, 
and 82706 VGA controller. Cost (1,000s): $160. 


Intel 
28F256 
Flash memory 


An extended-cycle flash memory. Organized 32K x 8. Can be erased and reprogrammed 126 
50,000 times, with a minimum specification of 10,000 cycles. Features a reprogramming 
failure rate during cycling of less than .05% over 10,000 cycles. Comes in a 32-pin ceramic 
DIP and 32-lead PLCC. Cost (10,000s): $25.90 (250 ns). 


National Semiconductor Controls and drives 256-Kbit and 1-Mbit DRAM arrays used with the NS32CG16 127 

NS32CG821 printer/display processor. Features a synchronous access mode and on-chip access-request 

DRAM controller logic. Includes refresh capabilities and support for page and static column-memory access 

modes. Comes in a 68-pin PLCC, in 20- and 25-MHz versions. Cost (100s): starts at $8.50. 


NCR An Arcnet controller/transceiver that integrates the functions of the NCR90C26 and 128 

NCR90C98 NCR90C32 and adds buffer chaining and reduced wait states. Controls up to 8 Kbytes of 

LAN controller/transceiver external RAM. Features three reset options. Comes in 40-pin DIPs and 44-pin PLCCs. 

Scheduled for production in February 1989. Cost (5,000s): $23. 


Renaissance GRX 
RVGAI 
VGA chip 


SBE 

VBIC-883, VSAM-883 
Chip set 


Texas Instruments 
SMJ34010 
Graphics processor 


A VGA chip compatible with the IBM VGA video display standard. Has hardware emula- 129 
tion of 17 IBM VGA modes, VGA resolution of 640x480 pixels in 16 simultaneous colors, 
and up to 256 simultaneous colors available. Comes in a 120-pin quad flatpack. Cost 
(1,000s): about $20. 

A VMEbus interface chip set that complies with IEEE P1014, Draft 1.2. Available in 130 

ceramic PGA versions that meet Mil-Std-883C. VSAM-883 implements the VMEbus slave 
interface. VBIC-883 implements the VMEbus master interface and Slot-1 functions. Cost 
(100s): $415 for VBIC-883; $315 for VSAM-883. 

A 32-bit, 40-MHz graphics processor for military systems. Has a 256-byte, on-chip instruc- 131 
tion cache; two register files, each with 15 32-bit registers; and an instruction set with 
mechanisms for manipulating single pixels or arrays of pixels. Comes in a 68-pin PGA. 

Cost (25s): $728.12. 


Western Digital 

FE5400SX 

Core logic chip set 


A core logic chip set for Intel’s 16-bit 80386SX processor that is hardware register and soft- 132 
ware compatible with IBM’s Micro Channel architecture. Operates at 16 MHz and sup¬ 
ports the 80387SX math coprocessor. Consists of four 132-pin JEDEC plastic quad flat 
pack devices. Cost (100s): $185. 
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CALL FOR PAPERS 

14TH Annual Conference On Local Computer Networks 

"The Conference on Practical Leading Edge Computer Networking" 

October 10-12, 1989, Minneapolis, Minnesota 

Sponsored by: IEEE Computer Society TC-Computer Communications 


Theme: 


General Co-Chairs: 


The emphasis of this conference is on practical experience using 
computer networks, including running applications by users, 
researchers, and vendors. 


Bob Linebarger, Brigham Young 

Ron Rutledge, Martin-Marietta Energy Systems 


This year's focus will be on Network Management and papers 
that cover these areas are expecially sought. 


Sessions Also Being Organized On: 


Protocols 
FDD I 
Wiring 
Performance 
Reliability 


Servers 

Security 

Standards 

Token-Rings 

Interconnecting 


Information for Authors: 

Submit 5 full copies. The first page must contain: title, authors’ 
names, affiliations, complete mailing address, telephone and fax 
numbers, and an abstract. Submit papers by May 15, 1989 
(double-spaced-in English) to: 

Larry Green 
Protocol Engines, Inc. 

1421 State Street 
Santa Barbara, CA 93101 
(805) 965-0825 
FAX (805) 564-8592 

UCB VAX 1UCSBCSL! WAVEFROIGREEN 


Important Dates: 

Submission Deadline May 15,1989 
Acceptance Notification June 19,1989 
Camera Ready Copy Due August 7,1989 


^ IEEE COMPUTER SOCIETY 


THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS. INC. 

IEEE 



Program Committee: 

Mark Cohn, Northrop (Co-Chair) 

Larry Green, Protocol Engines (Co-Chair) 
Hiroyuki Kusmoto, ElectrotechnicalLab 
(Asian-coordinator) 

Robert Zicari, Politenico di Milano 
(European-Coordinator) 

Ernst Biersack, Tech. Univ. Muenchen 

Carl Cargill, Digital 

Jeff Case, University of Tennessee 

Hasan Dandshy, Honeywell 

David Du, University of Minnesota 

A1 Leon-Garcia, University of Toronto 

Mario Gerla, UCLA 

Issac Ghansxah, California State University, 
Sacramento 

Per Gunningberg, Swedish Institute of 
Computer Science 
Anna Hac, AT&T Bell Labs 
John Hart, VitaLink 
James Herzog, Oregon State 
Hemant Kanakia, Stanford 
Debra Kornblum, BelCoRe 
Gerard Le Lann, INRIA 
Robert Love, IBM 

Dan Lynch, Advanced Computing Environments 

M. Misson University de Clermont-Ferrand II 

James Mollenauer, Prime Computer Vision 

Chiharu Ohsawa, Fuji Electric 

Radia Perlman, Digital 

Van Phung, Bell-Northern Research 

Daniel Pitt, IBM 

Jai Rao, McDonnell Douglas 

Howard Salwen, Proteon 

Anupan Shah, Computer Sciences Corporation 

Arien J. van der Wal, Eindhoven University 

A1 Weaver, University of Virginia 

Jeff Yaplee, Boeing Computer Services 


14th Annual Conference on Local Computer I intend to submit a paper entiUed: 

Networks 

C/O Ron Rutledge, M/S-6271 

Martin Marietta Energy Systems _ 

Oak Ridge National Laboratory 

Oak Ridge, TN 37831-6271 Name: 

(615) 576-7643 

RXZ@ORNLSTC. BITNET Address: 

RUTLEDGE @ MSR.EPM.ORNL.GOV 

FAX (615) 576-2912 _ 

Please send me: City: _State:_Zip: 

_Information as it becomes available Phone: _ 

_Advanced Program FAX: _ 

















Microsystem Announcements 


Company, Model, Function Comments R.S. No. 

Application Engineering An accelerator card for IBM PC-ATs and compatibles. Replaces the 80286 with a 16-MHz 135 
& Associates 80386 CPU. Does not require software drivers. Kit includes card, cable, and 80287 inter- 

386 Eagle-AT face module. Optional 8 Mbytes of 32-bit, one-wait-state extended memory. Cost: $1,200 

Accelerator board for kit; $3,400 (4 Mbytes) and $5,600 (8 Mbytes). 

AST Research Now shipping. An 8086-based coprocessor board for the Apple Macintosh SE that permits 136 

Mac86 running of MS-DOS applications. Shipped with version 2.01 software. Supports the Apple 

Coprocessor PC 5K-inch drive, DaynaFile, or IBM 3K-inch drive. Users can also access programs 

through LANs. Cost: $599. 

Austek Microsystems A 386AT design example board and documentation package based on the A38152 137 

Cobra/25 Microcache, a 25-MHz cache controller. Features 16 Mybtes of on-board memory capac- 

386AT cache system board ity, PC-AT compatibility, slow-down circuit, DMA invalidation, 8 full-size I/O slots, 

single-entry write buffer, and hidden DRAM refresh cycles. Cost: $3,400; free 30-day trial. 

Caplin Cybernetics A MicroVAX-resident, half-height, Q-bus, graphics and image processing card containing 138 

QTVIO an IMS T800 32-bit transputer with 2 Mbytes of DRAM. Has an 8-bit digitizer, eight 

Video I/O board programmable input lookup tables, two 512x512x8 framestores, a 512x512x4 overlay 

memory, and 24-bit image and overlay color palettes. No price given. 

Cordata Technologies A PC that runs IBM and Apple lie software. Features a 12-inch color monitor, two 139 

Color Bridge 360-Kbyte 5X-inch floppy disk drives, clock/calendar, and five video modes. IBM mode 

PC uses an 8088 CPU with 640 Mbytes of RAM; Apple mode has a 65C021 processor, a 65021 

display controller, and 128 Kbytes of Apple memory. Cost: $1,795. 

IDEAssociates A local PC communications kit consisting of a half-length card, adapter handler, diagnos- 140 

IDEAcomm 5251/AH tics program, and twinax cable. Designed for local AS/400 PC users who require PC Sup- 
Communications kit port access. Cost: $645 for PC version; $675 for PS/2 Micro Channel version; $80 for 

upgrade from IDEAcomm 5251 and 5251/Plus. 

Mercury Computer Systems RISC-based, double-precision attached processors with software support designed to 141 

MC6400 Series accelerate C and Fortran applications. Built around the Weitek XL-8064 chip set. Feature 

Attached processors 10 MIPS and 20 Mflops of performance with 64-bit accuracy. Operate with MS-DOS, 

OS/2, Unix System V.3, Aegis, and VMS. Cost: $14,700 (4 Mbytes of memory). 

Micronics Computers A 25-MHz 80386-based motherboard that supports the Weitek 3167 and Intel 80387 math 142 

2525 Weitek coprocessors. Operates at 8 MHz or 25 MHz. Has a 32-bit memory bus, five 16-bit IBM 

Motherboard PC-AT-compatible expansion slots, and two 8-bit IBM PC-XT-compatible expansion slots. 

Has expandable 32-bit memory up to 16 Mbytes. Cost: starts at $5,765 (4 Mbytes). 

Micro Resources A 68008 board designed to teach 68000 programming. Has an 8-MHz clock, an 8-bit exter- 143 

Mister-8 nal data bus, 64 Kbytes of static RAM, a total of 128 Kbytes of ROM in three application 

68008 processor board sockets, a 128-byte FIFO buffer (provided by Zilog 8038), and monitor EPROM. Cost: $345. 

National Instruments An extended resolution, multifunction analog, digital, and timing I/O board for the Apple 144 

NB-MIO-16X Macintosh II. An enhanced version of the NB-MIO-16 multifunction board. Has 16 analog 

Data acquisition interface input channels that it can digitize with 16-bit resolution, plus a new scanning mode, new 
trigger mode, and timed waveform generation. Cost: $1,695 (42 /js); $1,895 (18 fus). 

Quadram A register-level extended VGA graphics adapter board for the IBM PC-XT, PC-AT, or 145 

QuadVGA Spectra compatible. Works in an 8-bit or 16-bit slot. Comes with a 9-pin and a 15-pin connector to 

VGA adapter support digital and analog monitors. Comes with 256 Kbytes of 100-ns RAM upgradable to 

512 Kbytes. Cost: $549. 

Toshiba America A half-height CD-ROM disk drive with an average access time of 400 ms. Stores up to 680 146 

XM-3201B Mbytes of data and operates in both horizontal and vertical orientations. Features an 

CD-ROM disk drive embedded SCSI interface and audio capability. Cost (OEM quantities): less than $500. 

Tussey Computer Products A computer based on the 20-MHz 80386 with zero-wait-state memory. Contains the 147 

Swan 386/20 RAM-16 32-bit memory card with 1 Mbyte of memory expandable to 2 or 4 Mbytes using 

Computer 256-Kbyte SIMMS or 4, 8, 10, or 16 Mbytes using 1-Mbyte SIMMS. Comes in a tower case 

with five bays, an 80387 socket, and an 80287 socket. Cost: $2,499-$3,678. 
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The field of Computer-Aided Soft¬ 
ware Engineering (CASE) is the wide 
spread commercial application of 
software engineering techniques 
and computer technology to infor¬ 
mation systems development. 

CASE '89 provides a forum for solid, 
detailed exchange of ideas among 
key practitioners, researchers, devel¬ 
opers, and leading-edge users in 
the field, resulting in meaningful 
goals for the advancement of CASE 
technology. 

Working groups will review the 
current state-of-the-art, discuss 
research directions, and consider 
future requirements in the following 

■ Software Factories and Environ¬ 
ments 

- Relationship of CASE and IPSE 
-Modelling the Software 

Development Process 
—Environment Architectures and 
Public Tool Interfaces 

■ Management and Social Issues 

- Technology Transfer 
-Quality and Productivity Benefits 

- Cooperative Work 
—Introduction into Practice 
-Ensuring Safe Systems; Reducing 

Costs 

■ Systems Development Methods 
-Evolution of Methods 
-Socio-technical Approaches 
-Human-Computer Interaction 

■ Enabling Technologies 
-Formal Methods, Prototyping, 

Upper-CASE Languages 
-Data, Knowledge, and Object 
Bases; Hypertext 
—Hardware Innovations 

■ Maintenance 
-Reverse Engineering 
-Reusability 

■ Standards for CASE 


CASE '89 is a limited attendance 
workshop. Prospective attendees 
should submit 4 copies of a short 
position paper (500 words), in En¬ 
glish by April 7, 1989. 

Position papers should discuss the 
present state of the art, future direc¬ 
tions of CASE technology and prac¬ 
tical experience in the installation 
and use of CASE tools, or their 
objectives in seeking to attend 
CASE '89. 

In particular, the Program Commit¬ 
tee suggests the following guide¬ 
lines for position papers: 

■ Users should discuss what capa¬ 
bilities are needed now and what 
they are seeking in the future; 

• Researchers and Developers 
should explore what is possible to 
accomplish in the next five years; 

■ Vendors should review the present 
direction and constraints of CASE in 
the evolving five-year marketplace. 

In addition, the Program Committee 
is seeking a number of full length 
papers (max. 5000 words) dealing 
with any of the workshop topic 
areas. These papers will be refer¬ 
eed, and we hope to invite between 
20 and 30 authors to present briefly 
their ideas at the Workshop. 

It is particularly important that all 
authors respect the deadline for 
receipt of papers. 


General Chair 
John O. Jenkins 

Imperial College 
School of Management 
London, SW7 2PG, United Kingdom 
(+44) 01.589.5111 ext. 7112 
fax: (+44) 01.584.7596 

Program Chair 
M. M. Lehman 

Lehman Software Technology 
Associates and Imperial College 

North American 
Coordinator 
Elliot J. Chlkofsky 

Index Technology Corporation 
One Main Street 
Cambridge, MA 02142 USA 
617-494-8200 ext. 1989 
chikofsky@northeastern. edu 


Sponsored by: 

Imperial College 

In Cooperation With: 

British Computer Society 
Computer Society of the IEEE 
Index Technology Corporation 
PA Consultancy 
Imperial Software Technology 
The Serna Group pic 
Washington University CSDP 
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SUPERCOMPUTING 88 CONFERENCE 

Seymour Cray details gallium arsenide’s vital role in future Cray-3 



Seymour Cray (left) was one of three invited speakers at Supercomputing 88, and 
Steve Lundstrom (right) served as program chair. 


Edmund Gallizzi, Eckerd College 

The use of gallium arsenide will be 
the key to the lightning-fast speed of the 
soon-to-be-released Cray-3 supercom¬ 
puter, despite the fact its circuit struc¬ 
ture will be similar to that of the CDC 
1604, the first computer Seymour Cray 
designed 30 years ago. 

So said the Cray Research founder 
when he delivered the keynote address, 
“What’s This About Gallium 
Arsenide?” at the Supercomputing 88 
conference near Orlando, Florida, 
November 14-18. The IEEE Computer 
Society and the ACM sponsored the 
event. 

Additional invited Supercomputing 
88 speakers included Carl Conti, senior 
vice president and general manager of 
IBM Enterprise Systems, who called his 
banquet talk “The Future of Supercom¬ 
puting at IBM,” and Carl Ledbetter, 
vice president of marketing and sales at 
Control Data/ETA Systems, who titled 
his conference plenary talk “Glimpses 
of Infinity.” 

Other conference activities included 
three paper presentation tracks in appli¬ 
cations, software and algorithms, and 
architecture; the ACM’s 19th North 
American Computer Chess Champion¬ 
ship; the Supercomputer Facility 
Manager’s Workshop; vendor exhibits; 
research exhibits and demonstrations; 
the Visualization Theatre; panel discus¬ 
sions; and poster sessions. 

Consultant Stephen Lundstrom, the 
conference’s program chair, called the 
variety of activities “ ... an experiment 
in technology transfer.” The research 
exhibits, in particular, permitted hands- 
on viewing of research results. 

George Michael, who is with the 
Lawrence Livermore National Labora¬ 
tory and served as conference general 
chair, introduced the event as “the first 
in a new series of technical meetings for 
those connected with supercomputers, 
including manufacturers, suppliers, and 
users.” In support of the conference’s 
direction, Ledbetter stated at a news 
conference that he was very happy that 
a conference of this kind now exists. 


Michael said one goal of the conference 
was to provide a professional/technical 
program across disciplines that would 
also allow vendors to meet real super¬ 
computer users. 

Cray comparisons. The similarity 
Cray referred to lies in the fact that the 
Cray-3 is pushing the technology using 
gallium arsenide as the 1604 did using 
silicon. In each case, diode transistor 
logic (DTL) provides the best circuitry 
for circuit elements that have less than 
optimal operational characteristics. 

Cray expects the same future maturing 
for GaAs as silicon technology has real¬ 
ized since the 1604. 

Cray said the Cray-3 should be deliv¬ 
ered in the fourth quarter of 1989, and 
added that it will have 12 times the per¬ 
formance of a similarly priced Cray-2 
because of a factor of three from 
increased speed from each processor 
and a factor of four from the reduction 
in price per processor. 

The increased speed is a result of the 
use of GaAs, which he candidly stated 
was horrible to work with in a process 
sense. Currently, the yield of GaAs is 50 
percent and “that is good enough to 


make machines.” Cray expects the yield 
to improve. In looking for a GaAs sup¬ 
plier and a second source, Cray had lit¬ 
tle luck with the larger semiconductor 
companies. In support of small, risk¬ 
taking companies he said, “Thank 
heaven for startup companies or we 
would not have made progress. People 
unhappy with structure in a large com¬ 
pany give us our technological 
strength.” 

For historical perspective, Cray said 
the Cray-1 had one processor, executed 
80 million instructions per second and 
160 million floating-point operations 
per second, and had a clock time of 
12.5 nanoseconds. The Cray-2 had four 
processors for about the same price of a 
one-processor Cray-1, executed 480 
MIPS and 1,800 Mflops, and had a 
clock time of 4.1 nanoseconds. He 
seemed a little disappointed in the 
Cray-2 because he could not get fast 
enough integrated circuits. The exciting 
part of the machine was its liquid 
immersion cooling, he said. 

The Cray-3 will have 16 processors, 
execute 8,000 MIPS and 16,000 Mflops, 
and have a clock rate of 2 nanoseconds. 
Each CPU is composed of four modules 
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that are 4 inches square, 1 inch thick, 
and weigh 8 ounces. 

Prototype modules of the Cray-3 are 
working. Robots will be needed to 
assemble its very small components, 
which will be connected with laser weld¬ 
ing. The robots are expected to be oper¬ 
ational in the next few months. Looking 
into the future, Cray said the Cray-4 
will have a 1-nanosecond clock time and 
the Cray-5 might be biological. 

IBM’s reentry rationale. In a 

marketing-oriented banquet address, 
Conti stated that IBM reentered the 
supercomputing arena in 1985 because 
of the recognition of the value of super¬ 
computers in industry and the growing 
awareness that supercomputers are an 
important key to national competi¬ 
tiveness. 

“We don’t claim the most powerful 
systems when measured by peak 
megaflops,” Conti said. “We do 
claim—and we can back the claim— 
that the 3090 (VF) is the most successful 
parallel machine in the world.” 

In discussing IBM’s alliance with 
Supercomputer Systems and its founder 
Steve Chen, Conti said, “The machine 
we envision from this collaboration will 
contain as many as 64 parallel proces¬ 
sors and be 100 times more powerful 
than today’s most powerful computers. 
Our target for the system is the early 
1990s.” 

Focus on future. Ledbetter’s talk 
focused on the future of the US techno¬ 
logical and, in particular, supercom¬ 
puter leadership from a management 
viewpoint. 

“Although the challenge to our 
leadership, especially from Japan, is 
strong, I think we can accept it,” said 
Ledbetter. He noted that the Japanese 
take a long-term, strategic view of 
management, while, in contrast, Ameri¬ 
cans take a short-term, tactical view. 

“In particular, several Japanese elec¬ 
tronics companies use their large, verti¬ 
cally integrated structures to fund 
massive supercomputer research and 
development efforts,” he said. “They 
do this even though they know they’re 
going to lose money. In Japan, the 
manager’s success is based on the suc¬ 
cess the supercomputer brings in other 
terms, such as product penetration, 
market share, prestige, and the research 
and development effect it produces at 
lower levels of the product line years 
later.” 

In a criticism of American education, 
Ledbetter indicated that the degree has 
become an immediate economic pass¬ 
port. In Japanese universities “there is 
nearly twice as much supercomputing 


power than in American universities, 
for a student and faculty population 
one-sixth the size.” 

Ledbetter pointed out that the success 
of the supercomputer industry is sup¬ 
ported by the partnerships of industry, 
universities, and government. “In par¬ 
ticular, we use their expertise both for 
requirements and for debugging.” 

Each speaker expressed pride and 
value in his company’s partnerships, 
CDC/ETA with the US Department of 
Energy and Florida State University; 
IBM with Cornell University; and Cray 
with the Lawrence Livermore Lab. 

Visualization thread. Visualization, a 
method of computing that transforms 
the symbolic into the geometric and 
thus allows researchers to observe their 
simulations and computations, was one 
topic that pervaded each of the confer¬ 
ence’s events. The Visualization Theatre 
presented a two-hour program of video 
tapes and 3D 35mm film, most of which 
had been generated on supercomputers. 

The theater was presented by Maxine 
Brown, associate director of the Elec¬ 
tronic Visualization Laboratory, Uni¬ 
versity of Illinois at Chicago. The 
selections gave a sampling of various 
visualization techniques and uses in the 
three categories of entertainment, edu¬ 
cation, and research and design. 

Many of the research presentations 
included videotapes of research results, 
and some also included hands-on 
demonstrations in the exhibits. Lund- 
strom indicated that, in support of 
innovative technology transfer, the con¬ 
ference had committed a substantial 
budget to visualization. 

The Los Alamos National Labora¬ 
tory showed several visualization 
projects through research presentations 
and demonstrations. In the paper “A 
Scientific Visualization Workbench,” 
Richard Phillips of Los Alamos 
described an overall system to bring 
high-performance, interactive visualiza¬ 
tion to the scientific computing envi¬ 
ronment. 

Of the more than 30 vendor exhibits, 
20 were for super-type computers. Of 
these, the multimicroprocessor type 
computer was the largest group with 
nine vendors. Most of the systems used 
commercially available processors that 
included the Motorola M680XX, Inmos 
Transputer, and Intel 80386. The num¬ 
ber of processors ranged from 16 to 
1,024 or more. Most of the systems 
provided Unix as the operating system. 
The second largest group, composed of 
six, included the traditional type super¬ 
computers along with two Cray 
machine-language-compatible mini¬ 
supercomputers. 


The remaining architectures were of 
three types. Two machines were of the 
minisuper type with multiple proprie¬ 
tary vector processors. Two machines 
were of the single instruction, multiple 
data attached processor type that had a 
large number of interconnected one-bit 
processors. One system allowed as 
many as 65,536 processors, the other 
4,096 processors. Each used general- 
purpose workstations or minicomputers 
as the software development environ¬ 
ment, with executable code downloaded 
to the processors. One computer had a 
very long word architecture. 

Panel discussions. Two panels 
addressed the future of supercomputing 
from different standpoints. The 
“Grand Challenges for Supercomput¬ 
ing” panel, chaired by George Michael, 
presented the future supercomputing 
needs of several disciplines, including 
aerodynamics and aerospace structures, 
chemical and environmental science, 
biology, and physics. The ability to 
model larger and larger natural systems, 
requiring supercomputers with an exe¬ 
cution speed of at least 10 18 instructions 
per second, was the future goal of each 
of these disciplines. 

The second panel, “Impact of Future 
Technology in Supercomputing,” 
chaired by Duane Adams of Carnegie 
Mellon University, presented a report 
from the Supercomputing 88-sponsored 
preconference, “Future Technology 
Workshop.” The workshop attempted 
to answer the question of what kind of 
supercomputing will be available in 15 
years. 

Generally, the report said that future 
supercomputers will be massively paral¬ 
lel systems, with the flexibility of multi¬ 
ple instruction, multiple data 
architectures. Jack Dennis of MIT said 
that parallelism is a problem to the 
programmability of these systems, and 
to solve this problem, implicit parallel¬ 
ism must by supported by the com¬ 
pilers. Howard Davidson of Sun said 
there would be a technology divergence 
as CPU technology advanced rapidly 
while memory technology moved more 
slowly. This divergence would lead to 
systems that will require 50 CPU cycles 
to access memory. The base technology 
would include l-to-5 picosecond gate 
delays and 10 12 bytes of main memory. 

The industry representatives were 
somewhat more conservative. David 
Wehrly of IBM thought the report was 
overly optimistic with respect to the 
expectation of massively parallel 
general computing. He thought the 
future is “evolutionary, not revolu¬ 
tionary.” 

Gerald Brost of Cray Research said 
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he expects supercomputing to be much 
different in 15 years. He sees an 
increase in processors and posed the 
question: “But how many?” He 
thought a smaller number of CPU’s 
would provide a more flexible general- 
purpose computer. He said he does 
expect major growth in visualization. 

Richard Clayton of Thinking 
Machines said he expects cost/perfor¬ 
mance and networking will be major 
driving forces. Lloyd Thorndyke of 
ETA indicated that major developmen¬ 
tal areas will be architectures, electronic 


computer aided design, and packaging, 
and remarked that semiconductor 
development will be less of a problem. 

Chess tournament. The Deep 
Thought 0.02 system from the Depart¬ 
ment of Computer Science at CMU won 
the computer chess championship. The 
developer/participants were Thomas 
Anantharaman, Mike Browne, Murray 
Campbell, Feng-hsiung Hsu, and 
Andreas Nowatzyk. The system, which 
can search almost a million chess posi¬ 
tions per second, is composed of two 


special chess processors attached to a 
Sun 4. 

Chess Challenger X, a Motorola 
68030 microprocessor with the software 
written in assembly language, took sec¬ 
ond place. It was developed by Dan 
Spracklen, Kathe Spracklen, and Ron 
Nelson of Fidelity International. 
Mephisto X, using a Motorola 68020 
microprocessor and programmed in 
assembly language, placed third. It is 
the current World Microcomputer 
Chess Champion and was developed by 
David Lang of Hegener and Glaser A.G. 


presented at Compcon Spring 89 


Key Computer Society awards will be 

Glen Langdon, University of California at Santa Cruz 
Chuck Governale, Computer Assistant Editor 


Important IEEE Computer Society 
honors, the W. Wallace McDowell 
Award, two Computer Pioneer Awards, 
and the new Taylor Booth Award, will 
be presented during Compcon Spring 89 
in San Francisco February 27-March 3. 

The McDowell Award, the society’s 
highest technical honor, will go to John 
W. Poduska, Sr., founder and former 
chairman of Apollo Computer. He will 
be cited for his continued creative con¬ 
tributions to hardware and software 
developments and for management 
expertise in bringing them to products. 

Computer Pioneer Awards will be 
presented to Fritz L. Bauer of the Tech¬ 
nical University of Munich for develop¬ 
ing the first hardware stack for 
computers and to independent consul¬ 
tant Marcian E. (Ted) Hoff, Jr., for 
developing the concept and architecture 
for the first microprocessor on a chip, 
which led to implementation of the Intel 
MCS-4 and Intel 8080 families. 

The Booth Award will be presented 
to James T. (Tom) Cain of the Univer¬ 
sity of Pittsburgh (see story in the Com¬ 
puter Society News section). 

In addition, several Computer Soci¬ 
ety volunteers will be honored for con¬ 
tributing much of their time and talent 
to the success of society activities. 

On the technical program side, some 
very interesting tracks are planned dur¬ 
ing Compcon Spring 89. It will be a 
broad-based conference with a Silicon 
Valley flair, covering the previous 
year’s leading developments in the com¬ 
puting field. 

Products from Next, Cogent, Digital, 
MIPS, Hewlett-Packard, Silicon 
Graphics, and Nexgen will be featured 
in the workstation track. The software 
track will also be strong, with sessions 
on automating software design, window 
systems, software maintenance, parallel 
processing tools, and papers on parallel 


SQL, a Mach distributed operating sys¬ 
tem, groupware, security, and 
organithms. 

Leading developments in the 
microprocessor field will be covered in 
presentations on the Intel 80960, Moto¬ 
rola 88000, AMD 29000, TRON, and 
the Transputer. 

The high performance track will fea¬ 
ture parallel and retargetable instruc¬ 
tion sets by Myrias, a view of 
supercomputing environments from 
Evans and Sutherland, Encore’s shared 
memory approach, and Pacific 
Cyber/Metrics dataflow VME system. 

With ever-increasing processor 
speeds, the ability to move data around 
is increasingly important. This fast- 
moving field will be represented by 


Edmund Gallizzi 

Eckerd College 

“Tools that integrate disciplines so 
intermediate levels of abstraction are 
transparent to the user tend to eliminate 
the major hurdles and inhibitors and 
thus set the stage for dramatic surges of 
creativity and productivity.” 

That’s how Paul Hazan of Johns 
Hopkins University described the objec¬ 
tive of the event, Compusat 88: The 
Interdisciplinary World of Computing, 
he chaired October 4. This first in a 
series of planned satellite symposiums, 
sponsored by the IEEE Computer Soci¬ 
ety’s Technical Activities Board and the 
IEEE Educational Activities Board, was 
received at 130 sites and had more than 
6,000 viewers in the US, Canada, and 
Mexico. 

In disciplines whose knowledge base 
is growing in breadth and depth as fast 


innovations in the HSC standard, 
Ultra-bus, and Vectornet in one session 
and high-performance bus systems in 
another. 

Graphics will be covered in a session 
on scientific visualization and another 
entitled “Animation: It’s Not Just for 
Hollywood Anymore.” 

Design automation will be the focus 
at two sessions each on logic synthesis 
and on engineering information sys¬ 
tems, a session on quick turnaround 
ASICs, and one on design case histo¬ 
ries. Several emerging technologies are 
to be covered, including optical flop¬ 
pies, artificial neural networks, and dig¬ 
ital optical computers. 

Additional information about Comp¬ 
con Spring can be obtained on pp. 80 
A-H and 104 of the December 1988 
issue of Computer. 


as those of computer science and 
engineering, it is hard for practitioners 
and researchers to remain abreast of 
advances in any but their own dis¬ 
ciplines. 

This interdisciplinary symposium 
addressed the need for technology 
transfer. 

Hazan, along with Kenneth Anderson 
of Siemens and Laurel Kaleda of IBM, 
the Compusat Steering Committee 
cochairs, developed a program that 
looked at wide-ranging but coordinated 
topics in computer science and 
engineering. 

Divided into seven sessions, the 
topics included VLSI, chaired by 
Donald W. Bouldin of the University of 
Tennessee; design automation, chaired 
by Ronald Waxman of the University of 
Virginia; test technology, chaired by 
Thomas Williams of IBM; software 
engineering, chaired by Lorraine Duvall 


Inaugural Compusat fills the bill as an 
interdisciplinary technology-transfer vehicle 
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of Duvall Computer Technologies; per¬ 
sonal computing and office automa¬ 
tion, chaired by Stephen Ruth of 
George Mason University; machine 
intelligence and vision, chaired by J.K. 
Aggarwal of the University of Texas; 
and robotics, chaired by Mohan Trivedi 
of the University of Tennessee. 

The general structure of each of the 
sessions was to present the discipline’s 
basics, identify the state of the art, dis¬ 
cuss the current vanguard research, and 
then look at the future. 

In addition to the seven topic ses¬ 
sions, several question-and-answer 
periods were presented with the session 
chairs and guest panelists, including Les 
Belady of MCC, John Musa of AT&T 
Bell Laboratories, and Kaleda. 

In particular, Carver Mead of the 
California Institute of Technology, a 
presenter in the VLSI session, discussed 
the methods of user-designed integrated 
circuits. He said tools are available for 
integrated circuit design such as those 
from Silicon Compilers, as well as a 
new industry of semiconductor 
manufacturers who will manufacture 
your chip design for you. 

About the future, Mead said, “We 
have just begun learning how to do 
computation that is based on the para¬ 
digm you find in the brain, and in the 
long run—by “long run” I mean 20 
years—it is going to be as important 
economically as our digital paradigm.” 

John Hennessy of Stanford Univer¬ 
sity discussed architecture design within 
the contexts of instruction count, clock 
speed, cycles per instruction, and inte¬ 
grated circuit technology. The impor¬ 
tance of the relationships can be seen 
from the reduced instruction set com¬ 
puter which, for a particular task, 
would require a small increase in 
instruction count, but would allow a 
great decrease in cycles per instruction. 

Within these relationships, he said, 
“We have a real opportunity to come 
up with architectural innovations that 
respond to the characteristics of a given 
technology.” 

One of the real benefits of this type 
of Compusat forum is that many of the 
subjects, including graphical support of 
computer aided design systems and 
computer and communication system 
support for distributed conference and 
design team interactions, were clearly 
more comprehensible in a video format. 

A VLSI test workstation that allowed 
side-by-side on-screen displays of the 
graphical circuit design and a scanning 
electron microscope image of the actual 
circuit under test was a particularly 
impressive demonstration. A “virtual 
oscilloscope” allowed viewing of the 
signal at any point in the circuit. 
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First Symp. on Parallel Algorithms and 
Architectures: June 18-21, 1989, Santa Fe, 
N.M. Sponsor: ACM. Submit paper by Jan. 
20, 1989, to Larry Snyder, Computer Science 
Dept. FR-35, Univ. of Washington, Seattle, 
WA 98195. 

Eighth Biennial Univ./Government/Industry 
Microelectronics Symp.: June 12-14, 1989, 
Westborough, Mass. Sponsors: Int’l Society 
for Hybrid Microelectronics, IEEE. Submit 
paper by Jan. 20, 1989, to William M. 

Triggs, Massachusetts Microelectronics Cen¬ 
ter, 75 North Dr., Westborough, MA 01581. 

Sixth IEEE Workshop on Real-Time 

Operating Systems and Software: May 

11-12, 1989, Pittsburgh. Cosponsor: Car¬ 
negie Mellon Univ. Submit position paper by 
Feb. 1, 1989, to John B. Goodenough, Soft¬ 
ware Engineering Inst., Carnegie Mellon 
Univ., Pittsburgh, PA 15213, phone (412) 
268-6391. 

ICCD 89, IEEE Int’l Conf. on Com- 
vs7 puter Design: Oct. 2-4, 1989, Cam¬ 
bridge, Mass. Submit summary by Feb. 1, 
1989, to Sumit Das Gupta, IBM, Bldg. 306, 
ZIP 3A1, Hopewell Junction, NY 12533, 
phone (914) 894-0540. 

® Compsac 89, 13th Int’l Computer Soft¬ 
ware and Applications Conf.: Sept. 
20-22, 1989, Kissimmee, Fla. Submit paper 
and panel proposal by Feb. 1, 1989, Stanley 
Y.W. Su, 301 Computer Science and 
Engineering Bldg., Database Systems 
Research and Development Center, Univ. of 
Florida, Gainesville, FL 32611, phone (904) 
335-8458 or 8460. 

£3^ Arith 9, Ninth Symp. on Computer 
W Arithmetic: Sept. 6-8, 1989, Santa 
Monica, Calif. Cosponsors: IFIP, UCLA. 
Submit paper by Feb. 1, 1989, to Milos D. 
Ercegovac, Computer Science Dept., 3732C 
Boelter Hall, Univ. of California at Los 
Angeles, Los Angeles, CA 90024, phone 
(213) 825-5414. 


tions. Polytechnic Univ., 333 Jay St., Brook¬ 
lyn, NY 11201, phone (718) 260-3050. 

Int’l Conf. on Software Engineering and 
Knowledge Engineering: June 15-17, 1989, 
Chicago. Submit paper by Feb. 1, 1989, to 
C.Y. Hsieh, Computer Science Dept., 
Knowledge Systems Inst., 1153 Oak St., PO 
Box 576, Winnetka, IL 60093-0576. 


AMAST, Int’l Conf. on Algebraic Method¬ 
ology and Software Technology: May 22-24, 
1989, Iowa City, Iowa. Submit abstract by 
Feb. 1, 1989, to Eugene Madison or Teodor 
Rus, Computer Science and Mathematics 
Dept., Univ. of Iowa, Iowa City, IA 52242, 
phone (319) 335-0742 or 0694 (for the US); 
Dan Ionescu, Electrical Engineering Dept., 
Univ. of Ottawa, 770 King Edward, Ottawa, 
Ont., Canada NIK 6N5, phone (613) 
654-2211 (for Canada); or Maurice Nivat, 
Universite Paris, 2, Place Jussieu, 75005 
Paris, France, phone 33 (1) 43-25-98-74 (for 
Europe). 

Workshop on Automatic Verification 
Methods for Finite State Systems: June 
12-14, 1989, Grenoble, France. Sponsor: C- 
cube, the French National Project on Paral¬ 
lelism. Submit preliminary version of paper 
by Feb. 1, 1989, to Edmund M. Clarke, Car¬ 
negie Mellon Univ., Computer Science 
Dept., Pittsburgh, PA 15213; A. Pnueli, 
Weizmann Inst., Rehovot, Israel; or J. 
Sifakis, LGI-IMAG, BP 53X, 38041 Greno¬ 
ble Cedex, France. 

Third Workshop on Empirical Studies of 
Programmers: Apr. 29-30, 1989, Austin, 

Tex. Sponsor: Foundation for the Empirical 
Studies of Programmers. Submit panel pro¬ 
posal and/or position statement by Feb. 1, 
1989, to Gary Olson, Cognitive Science and 
Machine Intelligence Lab, Univ. of Michi¬ 
gan, Ann Arbor, MI 48109-1234, phone 
(313) 747-4948; or Elliot Soloway, Univ. of 
Michigan, EECS Dept., 1101 Beal Ave., Ann 
Arbor, MI 48109, phone (313) 936-1562. 


Network Management and Control Work¬ 
shop: Sept. 19-21, 1989, Tarrytown, NY. 
Sponsors: IEEE et al. Submit paper by Feb. 
1, 1989, to Basil Maglaris, Center for 
Advanced Technology in Telecommunica¬ 


ICNN 89, Int’l Conf. on Neural Networks: 

June 19-22, 1989, Washington, DC. Spon¬ 
sor: IEEE. Submit paper by Feb. 1, 1989, 
Nomi Feldman, 3770 Tansy St., San Diego, 
CA 92121, phone (619) 453-6222. 
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20th Southeastern International Conf. on 
Combinatorics, Graph Theory, and Comput¬ 
ing: Feb. 20-24, 1989, Boca Raton, Fla. 
Sponsor: Florida Atlantic Univ. Submit 
abstract by Feb. 3, 1989, to Frederick Hoff¬ 
man, Math Dept., Florida Atlantic Univ., 
Boca Raton, FL 33431, phone (407) 367-3345 
or 3340. 


Chapel Hill Workshop on Volume Visualiza¬ 
tion: May 18-19, 1989, Chapel Hill, N.C. 
Sponsor: Univ. of North Carolina, Molecu¬ 
lar Graphics Society. Submit paper by Feb. 

6, 1989, Frederick P. Brooks, Jr., Computer 
Science Dept., Univ. of North Carolina, 
Chapel Hill, NC 27599-3175. 

ICGA 89, Third Int’l Conf. on Genetic 
Algorithms: June 4-7, 1989, Washington, 
DC. Submit paper by Feb. 10, 1989, to J. 
David Schaffer, Philips Labs, 345 Scar¬ 
borough Rd., Briarcliff Manor, NY. 


® CSM 89, Conf. on Software Main¬ 
tenance: Sept. 25-28, 1989, Pensacola, 
Fla. Submit paper and panel session pro¬ 
posal by Feb. 15, 1989, to Capt. Thomas 
Pigoski, NSGD Pensacola, Corey Station, 
Pensacola, FL 32511, phone (804) 452-6399. 


Int’l J. Computer-Aided VLSI Design plans 
a special issue on placement and routing. 
Publisher: Ablex Publishing Corp. Submit 
paper by Feb. 28, 1989, to Mehdi Zargham, 
Computer Science Dept., Southern Illinois 
Univ., Carbondale, IL 62901-4511, phone 
(618)536-2327. 


IEEE Software: November 1989. Arti- 
W cles are sought for a special edition on 
reverse engineering. Submit manuscript by 
Mar. 1, 1989, to Elliot Chikofsky, Index 
Technology Corp., 1 Main St., Cambridge, 
MA 02142, phone (617) 494-8200. 


^ IEEE Trans. Computers: December 
vS7 1989. A special issue is planned on 
computer systems performance. Submit 
manuscript by Mar. 1, 1989, to Edward D. 
Lazowska, Computer Science Dept. FR-35, 
Univ. of Washington, Seattle, WA 98195, 
phone (206) 543-4755. 

Int’l J. Approximate Reasoning plans a spe¬ 
cial issue on belief functions and belief main¬ 
tenance in artificial intelligence. Submit 
paper by Mar. 1, 1989, to Prakash P. She- 
noy, School of Business, Univ. of Kansas, 
Summerfield Hall, Lawrence, KS 
66045-2003, phone (913) 864-7551; or Gau- 
tam Biswas, Computer Science Dept., Box 
1688, Station B, Vanderbilt Univ., Nashville, 
TN 37235, phone (615) 343-6204. 

Workshop on New Directions in Computer 
Chess: May 28-June 1, 1989, Edmonton, 
Alta., Canada. Sponsors: Int’l Computer 
Chess Assoc., Canadian Information Pro¬ 
cessing Society. Submit paper or abstract by 
Mar. 1,1989, to Tony Marsland, Computing 
Science Dept., Univ. of Alberta, Edmonton, 
Alta., Canada T6G2H1. 

32nd Midwest Symp. on Circuits and Sys¬ 
tems: Aug. 14-15, 1989, Urbana, Ill. Spon¬ 
sors: Univ. of Illinois at Urbana-Cham- 
paign, IEEE. Submit paper by Mar. 1, 1989, 
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to Sung Mo Kang, Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801- 
3082, phone (217) 244-0577. 

Manufacturing Int’l 90 Conf.: Mar. 25-28, 
1990, Atlanta. Sponsor: American Society of 
Mechanical Engineers. Submit abstract by 
Mar. 3, 1989, to Salah E. Elmaghraby, 

North Carolina State Univ., c/o ASME, 345 
E. 47th St., New York, NY 10017. 


GOMAC 89, Government Microcircuit 
Applications Conf.: Nov. 7-9, 1989, 
Orlando, Fla. Sponsors: US Dept, of 
Energy, et al. Submit summary by Mar. 17, 
1989, to Jay Morreale, G-89, Palisades Inst, 
for Research Services, 201 Varick St., Rm. 
1140, New York, NY 10014. 


© Eighth Symp. on Reliable Distributed 

Systems: Oct. 10-12, 1989, Seattle, 
Wash. Submit paper by Apr. 1, 1989, to Raif 
Yanney, TRW, DH2-2328, 1 Space Park, 
Redondo, Beach, CA 90278, phone (213) 
812-6033. 


Symp. on Design and Implementation of 
Large Spatial Databases: July 17-18, 1989, 
Santa Barbara, Calif. Submit paper by Apr. 
1,1989, to Oliver Gunther, Computer 
Science Dept., Univ. of California, Santa 
Barbara, CA 93106, phone (805) 961-3236. 

Seventh Pacific Northwest Software Quality 
Conf.: Sept. 11-12, 1989, Portland, Ore. 
Submit abstract by Apr. 3, 1989, to Dick 
Hamlet, Computer Science Dept., Portland 
State Univ., PO Box 751, Portland, OR 
97207-0751. 


CASE 89, Third Int’l Workshop on 
W Computer-Aided Software Engineer¬ 
ing: July 17-21, 1989, London. Cosponsors: 
Imperial College of London, Index Technol¬ 
ogy Corp. Submit position paper by Apr. 7, 
1989, to Elliot Chikofsky, Index Technology 
Corp., 1 Main St., Cambridge, MA 02142 
(for North America); or John Jenkins, 
School of Management, Imperial College, 
London SW7 2PG, UK (for other regions). 

Int’l Symp. on Computer Architecture and 
Digital Signal Processing: Oct. 11-14, 1989, 
Hong Kong. Sponsor: IEEE. Submit paper 
by Apr. 7, 1989, to W.C. Siu, Electronic 
Engineering Dept., Hong Kong Polytechnic, 
Hong Kong, phone (852) 3-638344, ext. 496. 

^ IEEE Software: January 1990. A spe- 
Hz cial issue is planned on software devel¬ 
opment metrics. Submit paper by Apr. 15, 
1989, to Peter Dyson, Software Productivity 
Solutions, 122 N. Fourth Ave., Indialantic, 
FL 32903, phone (407) 984-3370. 

Second IEEE Workshop on Worksta- 
Hz tion Operating Systems: Sept. 27-28, 
1989, Pacific Grove, Calif. Submit position 
statement by Apr. 15. 1989, to Luis-Felipe 
Cabrera, Mail Code K52/803, IBM Almaden 
Research Center, 650 Harry Rd., San Jose, 

CA 95120-6099. 


Eighth Int’l Conf. on Entity-Relationship 
Approach: Oct. 18-20, 1989, Toronto. Spon¬ 
sor: ER Inst. Submit paper by Apr. 15, 1989, 


to Frederick H. Lochovsky, Computer 
Science Dept., Univ. of Toronto, Stanford 
Fleming Bldg., 10 King’s College Circle, 
Toronto, Ontario M5S 1A4, Canada, phone 
(416) 978-7441. 

13th Western Educational Computing Conf.: 

Nov. 16-17, 1989, Burlingame, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Submit paper by Apr. 20, 1989, to 
Oliver Seely, Jr., Chemistry Dept., Califor¬ 
nia State Univ. at Dominguez Hills, 1000 E. 
Victoria St., Carson, CA 90747. 


Int’l J. Computer Aided VLSI Design plans 
a special issue on design simulation and 
implementation. Publisher: Ablex Publishing 
Corp. Submit paper by Apr. 30, 1989, to 
Harry W. Tyrer, Electrical and Computer 
Engineering Dept., University of Missouri, 
Columbia, MO 65211, phone (314) 882-6489. 


Supercomputing 89: Nov. 13-17, 1989, 
Reno, Nev. Cosponsor: ACM. Submit 
paper by May 1, 1989, to Gary Johnson, San 
Diego Supercomputer Center, PO Box 


Fourth Knowledge Acquisition for 
Knowledge-Based Systems Workshop: Oct. 
1-6, 1989, Banff, Canada. Sponsor: Ameri¬ 
can Assoc, for Artificial Intelligence. Submit 
draft paper by May 1, 1989, John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, Seat¬ 
tle, WA 98124, phone (206) 865-3253. 

J. Microcomputer Applications: January 
1990. A special issue is planned on trans¬ 
puter applications. Submit paper by May 1, 
1989, to F.J. Rammig, Paderborn Univ., FB 
17, Warburger Str. 100, 4790 Paderborn, 
West Germany, phone 49 (05251) 60-20-69. 

Int’l Conf. on Expert Planning Systems: 

June 27-29, 1989, Brighton, UK. Sponsor: 
Institution of Electrical Engineers. Submit 
paper by May 5, 1989, to Conf. Services, 
IEE, Savoy PL, London WC2R 0BL, UK, 
phone 44 (1) 240-1871, ext. 222. 

Fifth Int’l Congress on Advances in Non¬ 
impact Printing Technologies: Nov. 12-17, 
1989, San Diego, Calif. Sponsor: Society for 
Imaging Science and Technology. Submit 
abstract by May 22,1989, to John Moore, 
Tektronix, PO Box 500, MS 50-321, Beaver¬ 
ton, OR 97077, phone (503) 627-5067. 

Second Int’l Symp. on Artificial Intelligence: 

Oct. 23-27, 1989, Monterrey, Mexico. Sub¬ 
mit abstract and paper by May 31,1989, to 
Francisco J. Cantu, Inst. Tecnologico de 
Monterrey, ITESM Sue. Correos “J”, Mon¬ 
terrey, N.L., Mexico 64849, phone 52 (83) 
58-20-00. 


^ Fourth Int’l Workshop on High-Level 

Synthesis: Oct. 15-18, 1989, Ken- 
nebunkport, Maine. Cosponsor: ACM. Sub¬ 
mit extended abstract by June 16,1989, to 
Raul Camposano, IBM Research Div., T.J. 
Watson Research Center, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
945-3971. 
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CALENDAR 


January 1989 


Saudi Computer 89, Jan. 29-Feb. 2, Riyadh, 
Saudi Arabia. Contact Gerald G. Kallman, 5 
Maple Ct., Ridgewood, NJ 07450-4431, 
phone (201) 652-7070. 

89 Usenix Winter Technical Conf., Jan. 
30-Feb. 3, San Diego, Calif. Sponsor: Usenix 
Assoc. Contact Judith DesHarnais, Usenix 
Conf. Office, PO Box 385, Sunset Beach, 

CA 90742, phone (213) 592-1381. 

Database 89 Expo and Conf., Jan. 31-Feb. 

2, San Francisco. Contact Dana De Nardi, 
289 S. San Antonio Rd., No. 204, Los Altos, 
CA 94022, phone (415) 941-8440. 


Conf. Dept. A, Assoc, for Computing 
Machinery, 11 W. 42nd St., New York, NY 
10036. 

Compcon Spring 89, Feb. 27-Mar. 3, 

San Francisco. Contact Kenichi Miura, 
Computational Research Dept., MS B2-7, 
Fujitsu America, 3055 Orchard Dr., San 
Jose, CA 95134-2017, phone (409) 432-1300, 
ext. 5408 or 5723; or Roy Lee, Sandia 
National Labs, PO Box 969, Livermore, CA 
94551, phone (415) 294-2127. 

Securicom 89, Seventh Worldwide Congress 
on Computer and Communications Security 
and Protection, Feb. 28-Mar. 3, Paris. Con¬ 
tact SEDEP, 8, rue de la Michodiere, 75002, 
Paris, France, phone 33 (1) 47-42-40-30. 


February 1989 


March 1989 


Fifth Int’l Conf. on Data Engineering, 
NS7 Feb. 6-10, Los Angeles. Contact John 
Carlis, Computer Science Dept., Univ. of 
Minnesota, 207 Church St., SE, Min¬ 
neapolis, MN 55455, phone (612) 625-6092; 
Richard L. Shuey, Rensselaer Polytechnic 
Inst., Dept, of Computer Science, Troy, NY 
12180, phone (518) 276-8376; or Data 
Engineering 89, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

1989 Aerospace Applications Conf., Feb. 
12-17, Breckenridge, Colo. Sponsor: IEEE 
South Bay Harbor Section. Contact Harvey 
Endler, 15137 Gilmore St., Van Nuys, CA 
91411. 


^ North Carolina Symp. on Artificial 
Intelligence, Feb. 16-17, Research Tri¬ 
angle Park, N.C. Cosponsor: North Caro¬ 
lina State Univ. Contact Connie McElroy- 
Bacon or Belinda Niedwick, Division of 
Lifelong Education, North Carolina State 
Univ., Box 7401, Raleigh, NC 27695-7401. 


1989 Workshop on VLSI, Feb. 19-22, 

w Clearwater Beach, Fla. Contact Sami 
Al-Arian, Computer Science and Engineer¬ 
ing Dept., Univ. of South Florida, Tampa, 
FL 33602, phone (813) 974-3544. 

20th Southeastern International Conf. on 
Combinatorics, Graph Theory, and Comput¬ 
ing, Feb. 20-24, Boca Raton, Fla. Sponsor: 
Florida Atlantic Univ. Contact Frederick 
Hoffman, Math Dept., Florida Atlantic 
Univ., Boca Raton, FL 33431, phone (407) 
367-3345 or 3340. 

17th Computer Science Conf., Feb. 21-23, 

Louisville, Ky. Sponsor: ACM. Contact 


First Oregon Workshop on Software Met¬ 
rics, Mar. 1-2, Portland, Ore. Cosponsors: 
Oregon Center for Advanced Technology 
Education, Portland State Univ., Oregon 
State Univ. Contact Warren Harrison, Com¬ 
puter Science Dept., Portland State Univ., 
PO Box 751, Portland, OR 97207-0751, 
phone (503) 464-3108. 

Int’l Conf. on Expert Systems for Develop¬ 
ment, Mar. 1-3, Kathmandu, Nepal. 
Cosponsors: Asian Inst, of Technology, 
Royal Nepal Academy of Science and Tech¬ 
nology. Contact Division of Computer 
Science, AIT, GPO Box 2754, Bangkok 
10501, Thailand. 

Fourth Conf. on Hypercube Concurrent 
Computers and Applications, Mar. 6-8, 

Monterey, Calif. Sponsors: US Dept, of 
Energy et al. Contact John Gustafson, Div. 
1413, Sandia National Labs, PO Box 5800, 
Albuquerque, NM 87185. 

EMC 89, Eighth Zurich Symp. and Techni¬ 
cal Exhibition on Electromagnetic Compati¬ 
bility, Mar. 6-9, Zurich. Sponsor: Swiss 
Electrotechnical Assoc. Contact T. Dvorak, 
EMC 89, ETH Zentrum-IKT, CH-8092, 
Zurich, Switzerland, phone 41 (1) 256-2790. 


^ CAIA 89, Fifth Int’l Conf. on Artifi- 
W cial Intelligence Applications, Mar. 
6-10, Miami, Fla. Contact Elaine Kant, 
Schlumberger-Doll Research, Old Quarry 
Rd., Ridgefield, CT 06877-4108, phone (203) 
431-5516. 


Seventh IEEE Computer Fair, Mar. 
W 8-10, Huntsville, Ala. Joint sponsors: 
Huntsville IEEE Section, Huntsville IEEE 
Computer Society. Contact Connie Harbi- 


son, TotalCom, 1115 Church St., Suite H, 
Huntsville, AL, phone (205) 534-6383. 

NCAT, Seventh National Conf. on Ada 
Technology, Mar. 13-16, Atlantic City, NJ. 
Contact NCAT, US Army Communica¬ 
tions—Electronics Command, Attn.: 
AMSEL-RD-SE-CRM (Kay Trezza), Fort 
Monmouth, NJ 07703-5000, phone (201) 
532-1898. 


Tapsoft 89, Joint Conf. on Theory and Prac¬ 
tice of Software Development, Mar. 13-17, 

Barcelona, Spain. Sponsor: European Assoc, 
of Theoretical Computer Science. Contact 
Pere Botella, Facultat d’Informatica, Pau 
Gargallo, 5, 08028 Barcelona, Spain, phone 
34 (3) 333-8308. 


Workshop on Visual Motion, Mar. 

20-22, Irvine, Calif. Contact Ellen Hil¬ 
dreth, Artificial Intelligence Lab, 545 Tech¬ 
nology Square, Cambridge, MA 02139; or 
Brian G. Schunck, Electrical Engineering 
and Computer Science Dept., 1301 Beal St., 
Univ. of Michigan, Ann Arbor, MI 
48109-2122, phone (313) 747-1803. 


Mid-Lantic Electronics Show, Mar. 21-22, 

Valley Forge, Pa. Sponsor: Electronic 
Representatives Assoc. Contact Judith Gins¬ 
berg, 4113 Barberry Dr., Lafayette Hill, PA 
19444, phone (215) 828-2271. 


PCCC 89, Phoenix Conf. on Com- 
puters and Communications, Mar. 
22-24, Scottsdale, Ariz. Cosponsor: Arizona 
State Univ. Contact Thaddeus L.D. Regulin- 
ski, Loral Corp., PO Box 295, Goodyear, 

AZ 85338, phone (602) 925-7321. 


AISIG 89, Artificial Intelligence Sys- 
vSz terns in Government Conf., Mar. 
27-31, Washington, DC. Cosponsors: 
George Washington Univ., Mitre Corp. 
Contact Jude Franklin, 1500 Planning 
Research Dr., McLean, VA 22102, phone 
(703)556-1990. 


First Conf. on Innovative Applications of 
Artificial Intelligence, Mar. 28-30, Stanford, 
Calif. Sponsor: American Assoc, for Artifi¬ 
cial Intelligence. Contact AAAI, 445 Burgess 
Dr., Menlo Park, CA 94025, phone (415) 
328-3123. 


Eastern Multiconference, Mar. 28-31, 

Tampa, Fla. Sponsor: Society for Computer 
Simulation. Contact SCS, PO Box 17900, 
San Diego, CA 92117-7900, phone (619) 
277-3888; or Allan Rutan, Radar Systems 
Lab, Raytheon, Wayland, MA 01778, phone 
(617) 440-5088. 
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California State Univ., Fullerton et al. Con¬ 
tact Larry Canter, Computer Systems 
Approach, Inc., 1140S. Raymond Ave., 
Suite B, Fullerton, CA 92631, phone (714) 
738-3414. 


Eighth Symp. on Principles of Database Sys¬ 
tems, Mar. 29-31, Philadelphia. Sponsor: 
ACM. Contact Avi Silbershatz, Computer 
Science Dept., Univ. of Texas at Austin, 
Austin, TX 78712. 


© Workshop on Applied Computing 89, 
Mar. 30-31, Stillwater, Okla. Cospon¬ 
sors: National Science Foundation et al. 
Contact Donald D. Fisher, Oklahoma State 
Univ., CIS, Stillwater, OK 74078, phone 
(405) 624-5668. 


CMC 89, Colorado Microelectronics Conf., 
Mar. 30-31, Colorado Springs, Colo. Con¬ 
tact Conf. Secretary, CMC 89, Microelec¬ 
tronics Research Labs, Univ. of Colorado, 
Box 7150, Colorado Springs, CO 
90933-7150, phone (719) 593-3488. 


Western Educational Computing Conf., 
Mar. 30-31, Santa Cruz, Calif. Sponsor: 
California Educational Computing Consor¬ 
tium. Contact Judah Rosenwald, Extended 
Education, NAD 153, San Francisco State 
Univ., 1600 Holloway, San Francisco, CA 
94132, phone (415)338-1212. 


April 1989 


Second National Conf. on Telecommunica¬ 
tions, Apr. 2-5, York, England. Sponsor: 
Institution of Electrical Engineers. Contact 
1EE Conf. Services, Savoy PL, London 
WC2R 0BL, UK, phone 44 (1) 240-1871, ext. 
222 . 


ASPLOS III, Third Int’l Conf. on 
VS7 Architectural Support for Program¬ 
ming Languages and Operating Systems, 
Apr. 3-6, Boston. Cosponsor: ACM. Con¬ 
tact Joel Emer, DEC/MIT, 545 Technology 
Square (NE43-503), Cambridge, MA 02139, 
phone (617) 253-7341. 


Working Conf. on Visual Database Systems, 
Apr. 3-7, Tokyo. Cosponsors: IFIP, IPSJ. 
Contact IFIP TC-2 Working Conf., 

Tosiyasu L. Kunii, Information Science 
Dept., Faculty of Science, Univ. of Tokyo, 
7-3-1 Hongo, Bunkyo-ku, Tokyo 113, 

Japan, phone 81 (3) 812-2111, ext. 4116. 


Third Eurographics Workshop on Intelligent 
CAD Systems, Apr. 3-7, Texel, The Nether¬ 
lands. Sponsor: Center for Mathematics and 
Computer Science. Contact Marja Hegt, 
CMCS, Kruislaan 413, 1098 SJ Amsterdam, 
The Netherlands, phone 31 (20) 592-4058. 


FLAIRS 89, Second Florida Artificial Intelli¬ 
gence Research Symp., Apr. 3-7, Orlando, 
Fla. Contact Avelino J. Gonzalez, Computer 
Engineering Dept., Univ. of Central Florida, 
Orlando, FL 32816, phone (407) 281-5027. 


Int’l Symp. on Database Systems for 
Advanced Applications, Apr. 10-12, 

Seoul, Korea. Cosponsors: IPSJ, Korean 
Information Science Society. Contact Sukho 
Lee, Computer Engineering Dept., Seoul 
National Univ., Sinlim-Dong, Gwanak-ku, 
Seoul 151, Korea, phone 82 (2) 886-0101. 

MIV 89, Int’l Workshop on Industrial Appli¬ 
cations of Machine Intelligence and Vision, 
Apr. 10-12, Tokyo. Cosponsors: IEEE et al. 
Contact Mitsuru Ishizuka, Inst, of Industrial 
Science, Univ. of Tokyo, 7-22-1, Roppongi, 
Minato-ku, Tokyo, 106, Japan, phone 81 
(03) 470-5389. 

First Hong Kong Int’l Computer Conf., 

Apr. 10-14, Hong Kong. Sponsor: American 
Federation of Information Processing Socie¬ 
ties, et al. Contact George R. Eggert, 

AFIPS, 2200E Devon Ave., Suite 268, Des 
Plaines, IL 60018, phone (312) 299-4227; or 
Alex Tzang, Suite 705 East Town Bldg., 41 
Lockhart Rd., Hong Kong, phone 852 (5) 
286-136. 

Irfjk 1989 IEEE VLSI Test Workshop, Apr. 

11-13, Atlantic City, NJ. Sponsors: 
IEEE Computer Society Test Technology 
Committee, IEEE Philadelphia Section. 
Contact Wesley E. Radcliffe, IBM-CTD, 
B/321-5E1, D/277, East Fishkill Facility, 
Hopewell Junction, NY 12533, phone (914) 
894-4346. 

ETC 89, First European Test Conf., 
xa/ Apr. 12-14, Paris. Cosponsor: Societe 
des Electriciens et des Electroniciens. Con¬ 
tact Roger Cogonen, 36 Ave. Jean Janurs, 
95230 Soisy Sous, Montmorency, France, 
phone 33 (1) 39-89-03-46; or Colin Maunder, 
British Telecom Research Labs, Martlesham 
Heath, Ipswich, Suffolk IP5 7RE, phone 44 
(473) 642-706. 

NCGA 89, Apr. 17-20, Philadelphia. Spon¬ 
sor: National Computer Graphics Assoc. 
Contact NCGA, 2722 Merrilee Dr., Suite 
200, Fairfax, VA 22031, phone (800) 
225-6242. 

® First Symp. on Parallel and Dis¬ 
tributed Processing, Apr. 20-21, 

Dallas. Contact Behrooz Shirazi, Computer 
Science Dept., Southern Methodist Univ., 
Dallas, TX 75275, phone (214) 692-2874. 

Multimedia 89, Second Comsoc Int’l Mul¬ 
timedia Communications Workshop, Apr. 
20-23, Ottawa, Canada. Cosponsors: IEEE 
et al. Contact Ottawa Carleton Research 
Inst., 1150 Morrison Dr., Suite 302, Ottawa, 
Ont., Canada K2H 8S9, phone (613) 

726-8827. 

Infocom 89, Conf. on Computer Com- 
XS/ munications, Apr. 24-27, Ottawa, 
Canada. Contact Celia Desmond, Telecom 
Canada, 438 Bay St., FL5S (C5), South 
Tower, Toronto, Ont., Canada, M5G 2E1, 
phone (416) 581-2318. 

Vision 89, Apr. 25-27, Chicago. Sponsor: 
Society of Manufacturing Engineers. Con¬ 
tact Maria Nowakowski, SME, 1 SME Dr., 


Third Workshop on Empirical Studies of 
Programmers, Apr. 29-30, Austin, Tex. 
Sponsor: Foundation for the Empirical 
Studies of Programmers. Contact Gary 
Olson, Cognitive Science and Machine Intel¬ 
ligence Lab, Univ. of Michigan, Ann Arbor, 
MI 48109-1234, phone (313) 747-4948; or 
Elliot Soloway, Univ. of Michigan, EECS 
Dept., 1101 Beal Ave., Ann Arbor, MI 
48109, phone (313) 936-1562. 

CHI 89, Conf. on Human Factors in 
Computing Systems, Apr. 30-May 4, 

Austin, Tex. Cosponsors: ACM, Human 
Factors Society. Contact Claudia Raun or 
Bill Curtis, MCC, PO Box 200195, Austin, 
TX 78720, phone (512) 338-3798. 

34th Int’l Instrumentation Symp., Apr. 
30-May 4, Orlando, Fla. Sponsor: Instru¬ 
ment Society of America. Contact Frederick 
A. Kern, PO Box 65, Seaford, VA 23696, 
phone (804) 865-3269. 


May 1989 

1989 IEEE Symp. on Research in Secu- 
rity and Privacy, May 1-3, Oakland, 
Calif. Contact Terry V. Benzel, Trusted 
Information Systems, 11340 Olympic Blvd., 
Suite 265, Los Angeles, CA 90064, phone 
(213) 477-5828. 

Physical Design Workshop, May 1-3, 

nS 7 Newport Beach, Calif. Cosponsor: 
ACM. Contact Bryan Preas, Xerox, Palo 
Alto Research Center, 3333 Coyote Hill Rd., 
Palo Alto, CA 94304, phone (415) 494-4845. 

Third Al Research in Environmental Science 
Workshop, May 2-4, Washington, DC. Con¬ 
tact William R. Moninger, Environmental 
Research Labs, NOAA, R/E2, 325 Broad¬ 
way, Boulder, CO 80803, phone (303) 
497-6435. 

Sixth Canadian Symp. on Instructional 
Technology, May 3-5, Halifax, N.S., 
Canada. Sponsor: National Research Coun¬ 
cil Canada. Contact Laurier Forget, CSIT, 
Conf. Services, NRCC, Ottawa, Ont. K1A 
OR6, Canada, phone (613) 993-9009. 

20th Pittsburgh Conf. on Modeling and 
Simulation, May 4-5, Pittsburgh, Pa. Spon¬ 
sor: Univ. of Pittsburgh. Contact William G. 
Vogt or Marlin H. Mickle, 348 Benedum 
Engineering Hall, Univ. of Pittsburgh, Pitts¬ 
burgh, PA 15261. 

STA 5, Fifth Structured Techniques Assoc. 
Conf., May 8-11, Chicago. Sponsors: STA, 
ACM. Contact STA, c/o Robert Binder Sys¬ 
tems Consulting, Inc., 3 First National 
Plaza, Suite 1400, Chicago, IL 60602. 

34th Int’l SAMPE Symp., May 8-11, Reno, 
Nev. Sponsor: Society for the Advancement 
of Material and Process Engineering. Con- 
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STUDENT MEMBERSHIP APPLICATION 


Students, Membership Is Part Of Being A 
Professional... Join The Computer Society Now! 


As a student member of the 
Computer Society, you will have a 
wealth of resources for professional 
success, both in school and beyond. 
The student cost to join is much less 
than youd think—and the benefits, 
much greater. Among the many 
automatic benefits offered to IEEE/ 
Computer Society students are, 

□ Computer magazine monthly 

□ IEEE Spectrum, The Institute, 
and Potentials 

□ Local chapter activities 

□ Discounts on optional periodicals, 
Computer Society Press books, 
and conferences. 




AGREEMENT 



will abide by the IEEE constitution and bylaws, and its statements 'of policies' 
and procedures. 



THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS, INC. 


Nonstudents interested in membership: 


Student's signature 


Date 










































tact Marge Smith, SAMPE, PO Box 2459, 
843 W. Glentana, Covina, CA 91722, phone 
(818)331-0616. 

CompEuro 89, Int’l Conf. on VLSI 
and Computer Peripherals, May 8-12, 

Hamburg. Cosponsors: Gesellschaft fur 
Informatik et al. Contact Walter E. Proeb- 
ster, IBM Lab, PO Box 1380, D-7030 Boeb- 
lingen, Schonaicher Str. 220, Federal 
Republic of Germany, phone 49 (70) 
3116-3929. 

ICCAL 89, Second Int’l Conf. on 
Computer-Assisted Learning, May 9-11, 

Dallas. Sponsor: Computer Learning 
Research Center, Univ. of Texas at Dallas. 
Contact Janet Harris, Center for Continuing 
Education, Univ. of Texas at Dallas, PO 
Box 830688, MS CN 1.1, Richardson, TX 
75083-0688. 


Robots 13, May 9-12, Gaithersburg, Md. 
Sponsor: SME. Contact Rebecca Alsup, 
SME, 1 SME Dr., Dearborn, MI 48121, 
phone (313) 271-1500, ext. 358. 


CCC 89, Second Hungarian Custom Circuit 
Conf., May 10-12, Szeged, Hungary. 
Cosponsors: Scientific Society of Measure¬ 
ment and Automation (MATE). Contact 
MATE Secretariat, 1055 Budapest, Kossuth 
L. ter 6-8, Hungary, phone (1) 531-406. 


Sixth IEEE Workshop on Real-Time 
vB? Operating Systems and Software, May 
11-12, Pittsburgh. Cosponsor: Carnegie Mel¬ 
lon Univ. Contact Andre van Tilborg, Office 
of Naval Research, 800 N. Quincy St., 
Arlington, VA 22217-5000, phone (202) 
696-4302. 


AAMSI Congress 89, May 11-13, San Fran¬ 
cisco. Sponsor: American Assoc, for Medi¬ 
cal Systems and Informatics. Contact 
AAMSI, Suite 700, 1101 Connecticut Ave. 
NW, Washington, DC 20036, phone (202) 
857-1189. 


Int'l Conf. on Robotics and Automation, 
May 14-19, Scottsdale, Ariz. Sponsor: IEEE. 
Contact Harry Hayman, PO Box 3216, Sil¬ 
ver Spring, MD 20901, phone (301) 434-1990 
or (407) 483-3037. 


£j«k 11th Int’l Conf. on Software Engineer- 
ing, May 15-18, Pittsburgh. Cospon¬ 
sor: ACM. Contact Larry Druffel, Software 
Engineering Inst., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 
268-7740. 


Sixth Conf. on Real-Time Applications in 
Nuclear, Particle, and Plasma Physics, May 
15-18, Williamsburg, Va. Sponsors: IEEE et 
al. Contact Roy Whitney, 12000 Jefferson 
Ave., Newport News, VA 23606, phone 
(804) 249-7536. 

18th Mumps Users Group Annual Meeting, 
May 15-19, Seattle. Contact Mumps Users 
Group, 4321 Hartwick Rd., Suite 510, Col¬ 
lege Park, MD 20740, phone (301) 779-6555. 

SID 89, Society for Information Display 
Int’l Symp., Seminar, and Exhibition, May 


15-19, Baltimore. Contact Society for Infor¬ 
mation Display, c/o Palisades Inst, for 
Research Services, 201 Varick St., Rm. 1140, 
New York, NY 10014, phone (212) 620-3375. 


Int’l Symp. on VLSI Technology, Sys- 
v37 terns, and Applications, May 17-19, 

Taipei, Taiwan. Cosponsors: Republic of 
China National Science Council, Industrial 
Technology Research Inst. Contact Alice M. 
Chiang, MIT, Lincoln Lab, Lexington, MA 
02173-0073, phone (617) 981-4629. 


Chapel Hill Workshop on Volume Visualiza¬ 
tion, May 18-19, Chapel Hill, N.C. Sponsor: 
Univ. of North Carolina, Molecular 
Graphics Society. Contact Frederick P. 
Brooks, Jr., Computer Science Dept., Univ. 
of North Carolina, Chapel Hill, NC 
27599-3175 


© Fifth Int’l Workshop on Software 
Specification and Design, May 19-20, 

Pittsburgh. Cosponsor: ACM. Contact Sol 
J. Greenspan, GTE Labs, 40 Sylvan Rd., 
Waltham, MA 02254, phone (617) 466-2962; 
or Colin Potts, MCC, 9390 Research Blvd., 
Kaleido II Bldg., Austin, TX 78759, phone 
(512)338-3629. 


First IEEE Symp. on Parallel and Dis¬ 
cs' tributed Processing, May 22-23, 

Dallas. Sponsor: Dallas Section of the IEEE 
Computer Society. Contact Mark Shado- 
wens. Information Technologies Lab, Texas 
Instruments, PO Box 655474, MS 238, 
Dallas, TX 75265, or call Behrooz Shirazi at 
(214) 692-2874. 

AMAST, Int’l Conf. on Algebraic Method¬ 
ology and Software Technology, May 22-24, 
Iowa City, Iowa. Contact Eugene Madison 
or Teodor Rus, Computer Science and 
Mathematics Dept., Univ. of Iowa, Iowa 
City, IA 52242, phone (319) 335-0742 or 
0694. 


Sixth Int’l Conf. on Testing Computer Soft¬ 
ware, May 22-25, Washington, DC. Spon¬ 
sors: DPMA, ACM. Contact Genevieve 
Houston-Ludlam, Frontier Technologies, 
2444 Solomons Island Rd., Suite 205, 
Annapolis, MD 21401, phone (301) 
266-8244. 


10th Tunisian French Seminar of Com- 
puter Science: The Role of Languages 
in Programming, May 23-25, Tunis, Tunisia. 
Cosponsor: Tunisian Information Processing 
Society. Contact Abdelfettah Belghith, Dept, 
d’lnformatique, Faculte des Sciences de 
Tunis, 1002 Belvedere Tunisa; or Ali Mili, 
Faculty of Sciences, Univ. of Tunis II, 
Campus Universitaire, 1002 Belvedere, 
Tunisia. 

SIGMetrics 89 and Performance 89, May 
23-26, Berkeley, Calif. Sponsors: ACM, 

IFIP. Contact Luis-Felipe Cabrera, IBM 
Almaden Research Center, Mail Code 
K52/803, San Jose, CA 95120-6099, phone 
(408) 927-1838. 

ICCI 89, Int’l Conf. on Computing and 
Information, May 23-27, Toronto. Contact 


Waldemar W. Koczkodaj, Laurentian Univ., 
CoSc, Sudbury, Ont., Canada P3E 2C6, 
phone (705) 675-1151. 


Workshop on New Directions in Computer 
Chess, May 28-June I, Edmonton, Alta., 
Canada. Sponsors: Int’l Computer Chess 
Assoc., Canadian Information Processing 
Society. Contact Tony Marsland, Comput¬ 
ing Science Dept., Univ. of Alberta, Edmon¬ 
ton, Alta., Canada T6G 2H1. 


16th Int’l Symp. on Computer Archi- 
VJ/ tecture, May 28-June 1, Jerusalem, 
Israel. Cosponsor: ACM. Contact M. Yoeli, 
Computer Science Dept., Technion City, 
Haifa 32000, Israel, phone 972 (4) 294-314. 

19th Int’l Symp. on Multiple-Valued 

saz Logic, May 29-31, Guangzhou, China. 
Cosponsors: Chongging Univ. et al. Contact 
David M. Miller, Computer Science Dept., 
Univ. of Victoria, B.C., Canada, V8W 2Y2, 
phone (604)721-7220. 


CIPS National Congress 89, May 29-June 2, 

Edmonton, Alta., Canada. Sponsor: CIPS. 
Contact Congress 89, PO Box 1277, Main 
Post Office, Edmonton, Alta., Canada T5J 
2M8, phone (403) 488-1879 


Int’l Conf. on Systolic Arrays, May 
31-June 2, Killarney, Ireland. Cospon¬ 
sor: Queen’s Univ. of Belfast. Contact Earl 
Swartzlander, TRW, 1 Space Park, Redondo 
Beach, CA 90278, phone (213) 535-4321. 


June 1989 


IEEE Pacific Rim Conf. on Communica¬ 
tions, Computers, and Signal Processing, 
June 1-2, Victoria, B.C., Canada. Sponsor: 
IEEE Victoria Section, Univ. of Victoria. 
Contact Warren D. Little, Dept, of Electrical 
and Computer Engineering, Univ. of Victo¬ 
ria, PO Box 1700, Victoria, B.C., Canada 
V8W 2Y2, phone (604) 721-8686. 

ICGA 89, Third Int’l Conf. on Genetic 
Algorithms, June 4-7, Washington, DC. 
Contact J. David Schaffer, Philips Labs, 345 
Scarborough Rd., Briarcliff Manor, NY. 


® CVPR 89, Conf. on Computer Vision 
and Pattern Recognition, June 4-8, 

San Diego, Calif. Contact Rama Chellappa, 
PHE324, Electrical Engineering-Systems 
Dept., Univ. of Southern California, Univer¬ 
sity Park, MC-0272, CA 90089, phone (213) 
743-8559. 


Fourth Israel Conf. on Computer Sys- 
'4/ terns and Software Engineering, June 
5-6, Tel Aviv. Cosponsors: Israel Chapter of 
IEEE Computer Society, Information Pro¬ 
cessing Assoc, of Israel. Contact S. Koenig, 
Ortra Ltd., PO Box 50432, Tel Aviv 61500, 
Israel, phone 972 (3) 664-825. 

Fourth Symp. on Logic in Computer 
Science, June 5-8, Pacific Grove, 

Calif. Cosponsor: ACM. Contact Albert 
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PHYSICAL DESIGN WORKSHOP 


MODULE GENERATION 
AND SILICON COMPILATION 


Workshop 

Committee 

General Chairman 
Bryan Preas 
Xerox PARC 
3333 Coyote Hill Road 
Palo Alto, CA 94304 
(415) 494-4845 
Preas.pa@Xerox.Com 

Program Chairman 
Daniel Gajski 

University of California 
Department of Information 
and Computer Science 
Irvine, CA 92717 
(714)856-4155 
Gajski@ICS.UCI.Edu 

Benchmark Chairman 
Dwight Hill 

AT&T Bell Laboratories 
600 Mountain Avenue 
Murray Hill, NJ 07974 
(201) 582-7766 
dwight@research.att.Com 

Registration & Arrangements 
Jamie Kirkendall 
ACM 

11 West 42nd Street 
New York, NY 10036 
(212) 869-7440 
Jamie@ACMVM.BITNET 

Workshop Secretary 
Lorna Fear 
Xerox PARC 
3333 Coyote Hill Road 
Palo Alto, CA 94304 
(415) 494-4813 
Fear.pa@Xerox.Com 
Fax: (415)494-4471 


April 30, May 1 -3,1989 
The Queen Mary 
PierJ, Long Beach Harbor 
Long Beach, CA 90801 

The purpose of this Physical Design Workshop is to gain insights into, and to 
advance the understanding, theory, and practice of, the module generation and 
silicon compilation aspects of electronic design systems. Session topics will include 

• Layout Frameworks for Module Generation and Silicon Compilation 

• Analog Module Generation and Silicon Compilation 

• Module Generation from Schematics 

• Constraint-Driven Optimization 

• Description Languages for Behavioral Compilation 

• The State of the Art in Silicon Compilation 

• Design Models in Silicon Compilation 

• Silicon Compilation from VHDL 

• Knowledge Representation, Acquisition and Learning in Silicon Compilation 

A portion of the workshop will be devoted to the development of module generation 
and silicon compilation benchmarks that can be used to gain an understanding of the 
design process and to evaluate various layout systems. To further this goal, a rally 
will be held to evaluate the benchmarks. Participants are requested to execute 
the benchmarks and report their results at the workshop. 

Benchmarks will be available beginning January 15, 1989. A copy of the 
benchmarks can be obtained by writing or sending electronic mail to Module 
Generation Benchmarks, Microelectronics Center of North Carolina, P. O. 
Box 12889, Research Triangle Park, NC 27709, benchmarks@mcnc.org, (919) 
248-1915. 

Workshop registration packets can be requested by contacting Jamie Kirkendall by 
phone ((212) 869-7440), by electronic mail, (Jamie@ACMVM.BITNET), or by mail 
(ACM, 11 West 42nd St., New York, NY 10036). The packet will include hotel 
registration as well as workshop registration information. Requests for 
registration packets must be received by March 15, 1989. Registration 
material must be returned to ACM by April 1, 1989. Hotel reservations must 
be made by March 15,1989. 

Attendance is limited. In the event too many requests are received, preference will 
be given to those participating in the program or executing the benchmarks. 

THE COMPUTER SOCIETY OF THE IEEE ASSOCIATION FOR COMPUTING MACHINERY 

DESIGN AUTOMATION TECHNICAL COMMITTEE SPECIAL INTEREST GROUP ON DESIGN AUTOMATION 




Meyer, Computer Science Lab, MIT, 545 
Technology Square, Cambridge, MA 02139. 

Ninth Int’l Conf. on Distributed Com- 
puling Systems, June 5-9, Newport 
Beach, Calif. Contact Kane Kim, Computer 
Engineering Program, Electrical Engineering 
Dept., Univ. of California, Irvine, CA 
92717, phone (714) 856-5542. 

Working Conf. on Computer-Aided 
>S V Design Systems Using Artificial Intelli¬ 
gence Techniques, June 6-7, Tokyo. Cospon¬ 
sor: IFIP, IPSJ. Contact Akihiko Yamada, 
NEC, 4-14-22 Shibaura, Minato-ku, Tokyo 
108, Japan; or Kozo Kinoshita, Faculty of 
Integrated Arts and Sciences, Fliroshima 
Univ., 1-1-89 Sendamachi, Naka-ku, 
Hiroshima 730, Japan, phone 81 (82) 
249-9150. 

Third Int’l Workshop on Wafer Scale Inte¬ 
gration, June 6-8, Como, Italy. Sponsor: 
IFIP. Contact Mariagiovanna Sami, Dip. di 
Elettronica, Politecnico di Milano, Piazza 
Leonardo da Vinci 32, 1-20133 Milan, Italy, 
phone 39 (2) 23-99-35-16. 

Second Int’l Conf. on Industrial and 
Engineering Applications of Artificial 
Intelligence and Expert Systems, June 6-9, 

Tullahoma, Tenn. Cosponsors: ACM, Univ. 
of Tennessee Space Inst. Contact Moonis 
Ali, Univ. of Tennessee Space Inst., Tulla¬ 
homa, TN 37388, phone (615) 455-0631. 


Mjj Int’l Workshop on Hardware Fault 
viz Tolerance in Multiprocessors, June 
19-20, Urbana, Ill. Contact Prith Banerjee, 
Coordinated Science Lab, Univ. of Illinois, 

1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 333-6564. 

CHDL 89, Ninth Int’l Symp. on Com- 
puter Hardware Description Languages 
and Applications, June 19-21, Washington, 
DC. Cosponsors: IFIP, ACM. Contact John 
A. Darringer, IBM T.J. Watson Research 
Center, PO Box 218, Yorktown Heights, NY 
10598, phone (914) 945-1018. 

© Fourth Structure in Complexity Theory 
Conf., June 19-22, Eugene, Ore. 
Cosponsors: Univ. of Oregon, ACM. Con¬ 
tact Stephen R. Mahaney, Rm. 2C-454, 
AT&T Bell Labs, 600 Mountain Ave., Mur¬ 
ray Hill, NJ 07974. 

ICNN 89, Int’l Conf. on Neural Networks, 
June 19-22, Washington, DC. Sponsor: 
IEEE. Contact Nomi Feldman, 3770 Tansy 
St., San Diego, CA 92121, phone (619) 
453-6222. 

NECC 89, 10th National Educational 
Computing Conf., June 20-22, Boston. 
Cosponsor: Int’l Council for Computers in 
Education. Contact Michael C. Mulder, 
Applied Research, Univ. of Portland, 5000 
N. Willamette Blvd., Portland, OR 97203, 
phone (503) 283-7433; or NECC 89, ICCE, 


FTCS 19, Int’l Fault-Tolerant Com- 
puting Symp., June 21-23, Chicago. 
Contact S.M. Reddy, FTCS 19, Electrical 
and Computer Engineering Dept., Univ. of 
Iowa, Iowa City, IA 52242, phone (319) 
335-5196; or Ravi K. Iyer, Coordinated 
Science Lab, Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801, phone 
(217) 333-9732. 

SIGPIan 89, Conf. on Programming Lan¬ 
guage Design and Implementation, June 
21-23, Portland, Ore. Sponsor: ACM. Con¬ 
tact Bruce Knobe, Prime Computer, Inc., 

500 Old Connecticut Path, Framingham, 

MA 01701, phone (508) 879-2960. 

CAR 89, Computer-Assisted Radiol- 
ogy Conf., June 25-28, Berlin. 
Cosponsor: AMK Berlin. Contact Michael 
L. Rhodes, MPDI, 2730 Pacific Coast Hwy., 
Torrance, CA 90505, phone (213) 539-5944. 

® DAC 89, 26th Design Automation 
Conf., June 25-29, Las Vegas. 
Cosponsor: ACM. Contact Michael J. 
Lorenzetti, MCNC, PO Box 12889, Research 
Triangle Park, NC 27709-2889; or Pat 
Pistilli, MP Associates, 7490 Clubhouse Rd., 
Suite 102, Boulder, CO 80301, phone (303) 
530-4333. 


State Sponsored Chair and 
Professor in Computer Science 


NJIT invites nominations for and applications from distinguished 
researchers for the New Jersey State Sponsored Chair in 
Computer Science. The candidate will be expected to provide 
strong research leadership and pivotal work in any areas of 
integrated systems such as software engineering, distributed 
knowledge base systems, computer communications and 
networking, database systems and languages, and distributed 
computing. Candidates should be nationally and internationally 
recognized for their contributions and should have proven 
academic/industrial experience. He/she can expect a competitive 
salary for a distinguished professorship plus a research budget 
commensurate with responsibilities. 

Computer and Information Science is a rapidly expanding 
department with the largest program in NJ, and offers B.S., 

M.S., and Ph.D. programs. CIS has extensive laboratory facilities 
offering excellent potential for industrial support. 

NJIT is the public technological university of New Jersey, with 
nearly 8,000 students enrolled in baccalaureate through doctoral 
programs in four colleges: Newark College of Engineering, the 
School of Architecture, the School of Industrial Management and 
College of Science and Liberal Arts. 

NJIT does not discriminate on the basis of sex, race, color, religion, national 
or ethnic origin, or age in employment. 

Send resume: Personnel Box CIS. 
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Have you heard about our... 

Technical 
Committee on 
Microprocessors 
and 

Microcomputers? 

For information on this, or any of our 32 
other TCs, members* may contact 


THE COMPUTER SOCIETY 

10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 
Telephone: (714) 821-8380 

Nonmembers! Circle reader service number 202 
for membership information. 
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RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine; 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 


CLARKSON UNIVERSITY 

The Clarkson University Mathematics and 
Computer Science Department is interested 
in hiring a faculty member in the areas: (a) 
Computer science, in particular theoretical 
computer science: (b) computational mathe¬ 
matics; (c) pure mathematics, in particular 
differential geometry and algebraic topology. 
Teaching load is two courses per semester. 
Salary and benefits are outstanding. 

Interested applicants should send resume 
and three letters of recommenation to Pro¬ 
fessor A.S. Fokas, Chairman, Department 
of Mathematics and Computer Science, 
Clarkson University, Potsdam, NY 13676. 

Clarkson University is an Affirmative Ac¬ 
tion/Equal Employment Opportunity Em¬ 
ployer MFVH (Minority, Female, Veteran, 
Handicap). 


SANTA CLARA UNIVERSITY 
Tenure Track Position In 
Computer Engineering 

Santa Clara University’s EECS depart¬ 
ment has an immediate opening for a tenure 
track faculty position in Computer Engineer¬ 
ing. Candidates with specialization in Com¬ 
puter Architecture or Software Engineering. 

Applicants must have a Ph.D. in Com¬ 
puter Engineering or a closely related area 
with a commitment to both teaching and re¬ 
search. Senior applicants must have a distin¬ 
guished research and teaching record. 

SCU is located 45 miles south of San 
Francisco, in the center of Silicon Valley. 
The department offers B.S., M.S., and 
Ph.D. degrees in both computer and Elec¬ 
trical Engineering. Engineering computing 
facilities include more than 70 engineering 
workstations, besides a VAX-11/750. Uni¬ 
versity academic computing resources in¬ 
clude a VAX-8650 plus more than 800 IBM 
PCs. Most computing facilities are net¬ 
worked together over a campus wide local 
area network. 

Candidates should submit a resume includ¬ 
ing the names of at least three references to: 
Dr. Hasan S. AlKhatib, Chairman 
Faculty Search Committee 
EECS Department 
Santa Clara University 
Santa Clara, California 95053 
E-mail: HALKHATIB@SCU.BITNET 
Santa Clara University is an Affirmative 
Action/Equal Opportunity Employer, 


THE GEORGE WASHINGTON 
UNIVERSITY 

Computer Science Faculty Positions 

Computer Science faculty positions at the 
Assistant, Associate and Full Professor ranks 
are available commencing Fall Semester 
1989. 

Especially sought are applicants able to 
conduct research and teach in the overlap¬ 
ping areas of image processing, machine 
vision and artificial intelligence. Candidates 
should have an earned Doctorate and re¬ 
search experience with an interest in both 
teaching and research. Ability to attract 
funded research is valued. The George 
Washington University is located in the 
center of Washington, DC. This metropoli¬ 
tan area sustains the second largest concen¬ 
tration of research and development activity 
in the United States, creating a continuing 
demand for rigorously-trained engineers and 
many research opportunities. Our Depart¬ 
ment is the largest in the School of Engineer¬ 
ing & Applied Science with 38 full-time 
faculty, accredited electrical engineering, 
computer engineering, and computer sci¬ 
ence degree programs, a large graduate and 
undergraduate student body, and a sub¬ 
stantial research budget. Current funded 
research projects include computer graphics, 
computer security, data transmission stan¬ 
dards and compression, fast packet switch¬ 
ing, image processing, intelligent user inter¬ 
faces, laser shields, MHD plants, magnetic 
devices, medical imaging, multipath fading 
and encryption, remote sensing, space-based 
radar, and special-purpose VLSI designs. 
Send curriculum vita, list of publications and 
3 references to: 

Professor James D. Foley, Chairman 
Department of Electrical Engineering & 
Computer Science 

School of Engineering & Applied Science 
THE GEORGE WASHINGTON 
UNIVERSITY 
Washington, DC 20052 
The George Washington University is an 
equal opportunity/affirmative action 
employer. 


PRINCETON UNIVERSITY 

The Department of Electrical Engineering 
invites applications for a full time, tenure- 
track faculty position. The discipline of par¬ 
ticular interest is Computer Engineering with 
a specialization in an area such as: CAD for 
integrated circuits and systems, fault toler¬ 
ance and computer architecture, VLSI, 
automated synthesis of digital systems. 
Please send a complete resume, a descrip¬ 
tion of research and teaching interests and 
names of three references to Professor Stuart 
Schwartz. Chairman, Dept, of EE, Princeton 
University, Princeton, NJ 08544. An Affir¬ 
mative Action/Equal Opportunity Employer. 


DUKE UNIVERSITY 
Department of Computer Science 

The Duke University Department of Com¬ 
puter Science is recruiting junior faculty in 
theoretical computer science and in bio¬ 
medical scientific computing. Applicants 
must demonstrate excellence in research or 
exhibit the promise of excellence. 

The Department currently has seventeen 
tenure track faculty, approximately 200 
undergraduate majors and 70 graduate stu¬ 
dents pursuing master’s and/or doctoral 
degrees. 

The Department has major research ef¬ 
forts in scientific computing with emphasis 
on numerical linear algebra, the solution of 
PDEs, and VLSI simulation; computer sys¬ 
tems with emphasis on computer architec¬ 
tures, modeling of fault-tolerant systems, 
systems performance, and communications; 
artificial intelligence, particularly in the areas 
of natural language interface, search meth¬ 
odologies, and expert systems; and theory 
and algorithms with emphasis on combina¬ 
torial and graph-theoretic studies. Special 
motivation for the research efforts comes 
from the areas of medical applications (in 
collaboration with the Duke Medical Center), 
and VLSI (in collaboration with the Micro¬ 
electronics Center of North Carolina, of 
which Duke is a Participating Institution). 

Interested applicants should send copies 
of their resumes and other supporting 
material by February 14, 1989, to: 

Professor Donald J. Rose 
Department of Computer Science 
Duke University 
Durham, NC 27706 

Duke University is an affirmative action, 
equal opportunity employer. 


LOUISIANA STATE UNIVERSITY 
Computer Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering at LSU invites applica¬ 
tions for anticipated tenure-track and visiting 
faculty positions available August 1989 in all 
areas of computer engineering, including 
microprocessors, distributed processing sys¬ 
tems and special purpose architectures. A 
Ph.D. or equivalent and potential for excel¬ 
lence in teaching and research are neces¬ 
sary. Rank is open. Salary is competitive and 
commensurate with qualifications and ex¬ 
perience. Release time and resources are 
provided in order to enhance the develop¬ 
ment of a quality research program. Oppor¬ 
tunities for summer support are available. 
Send resume, names of three references, a 
statement of teaching and research interests, 
and verification of employment eligibility in 
compliance with the Immigration Reform 
and Control Act of 1986 to: Alan H. Mar¬ 
shak, Chairman, Electrical and Computer 
Engineering, Louisiana State University, 
Baton Rouge. LA 70803-5901. LSU is an 
Equal Opportunity Employer. 
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CLEVELAND STATE UNIVERSITY 
Computer 

Instructor or Asst. Professor 

The Department of Computer and Infor¬ 
mation Science at Cleveland State Universi¬ 
ty has a tenure track position in the areas of 
distributed systems or software engineering 
and design. Responsibilities include teaching 
(two courses/quarter) & research. Salary is 
very competitive. Qualifications: Ph.D. in 
Computer Science, MIS, or a closely related 
field. Ph.D. candidates with substantial pro¬ 
gress on a dissertation will be considered. 
Close relationships to business, engineering, 
and other departments provide an environ¬ 
ment conducive to research and consulting. 
In addition to university computing facilities, 
the department has laboratories using VAX 
computers running UNIX, VMS, and state of 
the art software. Faculty offices are equipped 
with personal computers. Inquiries and vita 
should be sent to: Dr. Thomas S. Heines, 
Chairperson, Computer & Information Sci¬ 
ence Dept., Cleveland State University, E. 
24th & Euclid Ave., Cleveland, OH 44115. 
Equal Opportunity Employer, m/f/h. 


MICHIGAN STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science in¬ 
vites applications for tenure track positions at 
all levels. Candidates from all areas of 
specialization in computer science or com¬ 
puter engineering will be considered. The 
department has a special interest in candidates 
in the areas of programming languages, ar¬ 
tificial intelligence and expert systems, design 
of computer systems and networks, parallel 
computation, and operating systems. Can¬ 
didates should have a Ph.D. in computer 
science or computer engineering and have a 
strong interest in both research and teaching. 
One position is available starting in January 
1989. Additional positions are anticipated 
beginning in September 1989. Initial screen¬ 
ing of applications will begin on August 1, 
1988. However, applications will be accepted 
until the positions are filled. 

As a unit within the College of Engineering 
at Michigan State University, Computer 
Science offers the Bachelor of Science, Master 
of Science and Doctor of Philosophy degrees. 
Special support is available from within the 
college and university to initiate research by 
new faculty members. Faculty offices are con¬ 
nected to the MSUnet which provides access 
to an an-ay of campus computing resources 
including the facilities of the College of Engi¬ 
neering, the Department’s VAX 8600 and 
64-node NCUBE, Pattern Recognition and 
Image Processing Laboratory. Artificial In¬ 
telligence/Knowledge Based Systems Labo¬ 
ratory and the Distributed Computing Re¬ 
search Laboratory. Access to select off- 
campus computers is available, as well as ac¬ 
cess to ARPANET, CSNET, B1TNET and 
MAILNET. Additional facilities available to 
faculty include an IBM 3090/180E vector 
processor, the College’s A.H. Case Center for 
Computer-Aided Engineering and Manufac¬ 
turing, and the Electronics Research and 
Development Laboratory. 

Michigan State University enjoys a park-like 
campus of 2,100 developed acres and 3,100 


acres of experimental farms, outlying research 
facilities and natural areas. The campus is ad¬ 
jacent to the cities of East Lansing and the 
capital city, Lansing. The Greater Lansing 
area has approximately 250,000 residents. 
The communities have fine school systems 
and place a high value on education. 

Applicants should send a resume and a 
statement of research and teaching interests 

Dr. Anthony S. Wojcik, Chairperson 
Department of Computer Science 
A714 Wells Hall 
Michigan State University 
East Lansing, Michigan 48824-1027 
CSNET: wojcik % cps.msu.edu 
Michigan State University is an Equal Op¬ 
portunity/Affirmative Action Institution and 
encourages applications from members of 
ethnic minority groups. 


UNIVERSITY OF CALIFORNIA 
AT IRVINE 

Faculty Positions in Computer Science 

The Department of Information and 
Computer Science (ICS) is actively recruiting 
new faculty members. We have energetic re¬ 
search groups in the areas of architecture 
and operating systems, artificial intelligence 
and machine learning, software engineering 
and programming environments, social and 
managerial analysis of computing, and data 
structures and algorithms. We are currently 
building on these areas of existing strength. 

We are looking for energetic, congenial 
candidates who would thrive in a serious but 
friendly research setting, and who would like 
to join us in exploring the nature of comput¬ 
ing, broadly defined. Exceptionally distin¬ 
guished candidates for senior positions are 
especially encouraged to apply. 

The ICS Department is an independent 
academic unit reporting to the Executive 
Vice Chancellor. ICS maintains an emphasis 
on core computer science as well as effective 
interdisciplinary ties to colleagues in 
Neurobiology, Cognitive Science, Manage¬ 
ment, Engineering, and other areas. The 
department currently has 25 full-time faculty 
positions and 85 Ph.D. students, with major 
support from the administration to expand 
and to strengthen the research environment. 
Annual research contracts from DARPA, 
NSF, ONR, and other agencies currently 
total over $3 million. In 1986 the Depart¬ 
ment was awarded a Coordinated Experi¬ 
mental Research (CER) grant from the Na¬ 
tional Science Foundation. This support is 
fostering the creation of a Laboratory for 
Software Research, in which major studies of 
the development and evaluation of software 
technology can be undertaken. It is also 
being used to strengthen the base of 
machines supporting other software re¬ 
search. Department equipment includes 
over 100 workstations, primarily Sun-3’s. 
Two large multiprocessor Sequents are 
available, as well as approximately 75 
Macintosh Plus's and II’s. Several laser 
printers are available for high-quality output. 
All machines are tied together with net¬ 
works, which are gatewayed to the campus 
network, and from there, to regional, na¬ 
tional, and international networks (Darpa In¬ 


ternet, CSnet, Bitnet, etc.). In addition, 
department members have access to cam- 
pus-wide computing resources as well as 
regional supercomputer access. 

UCI is located in Orange County, three 
miles from the Pacific Ocean near Newport 
Beach, and approximately halfway between 
Los Angeles and San Diego. The campus is 
situated in the heart of a national center of 
high-technology enterprise, and is experi¬ 
encing substantial growth with exciting 
opportunities. Salaries and benefits are com¬ 
petitive. Special housing assistance is avail¬ 
able from the university, including newly 
built, for-sale housing within short walking 
distance from the Department. 

Send resumes and names of four refer- 

John L. King, Chair 
Department of Information 
and Computer Science 
University of California 
Irvine, CA 92717 

Apply before March 1, 1989, to ensure 
consideration. 

An Affirmative Action/Equal Opportunity 
Employer. 


UNIVERSITY OF CALIFORNIA, 
DAVIS 

Faculty Positions in Electrical 
Engineering and Computer Science 

The Department of Electrical Engineering 
and Computer Science at UC Davis invites 
applications for tenure track positions at all 
ranks. The primary areas of interest are im¬ 
age processing, computer engineering, com¬ 
puter science, and optoelectronics. 

The department, with forty-six faculty 
members and 150 full-time graduate stu¬ 
dents, is experiencing rapid growth. Our 
College is the nation's sixteenth largest pro¬ 
ducer of engineering Ph.D.’s in a University 
which has the nineteenth largest extramural 
research funding. Salary and benefits are ex¬ 
tremely attractive. 

Davis is a pleasant, family-oriented com¬ 
munity near Sacramento, within easy driving 
distance to Silicon Valley, the Lawrence 
Livermore National Laboratory, San Fran¬ 
cisco, the Pacific Ocean, and the Sierra 
Nevada Mountains. 

We are seeking individuals with strong 
records of teaching and research and with 
ambitious plans. Senior appointments re¬ 
quire outstanding records of achievement; 
junior appointments must show evidence of 
great promise."All faculty are expected to 
have a strong commitment to teaching at all 
degree levels, and to demonstrate the ability 
to attract significant research support. 

The positions require a Ph.D. degree or 
equivalent, and are open until filled. Send a 
resume and the names of at least three refer- 

Professor S. Louis Hakimi, Chair 

Attention: Faculty Search Committee 

Department of Electrical Engineering and 
Computer Science 

University of California 

Davis, CA 95616 

The University of California, Davis, is an 
equal opportunity/affirmative action 
employer. 
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UNIVERSITY OF WISCONSIN- 
MILWAUKEE 

Distinguished/Chaired Professor 
in Computer Science 
Department of Electrical Engineering 
and Computer Science 

The Department of Electrical Engineering 
and Computer Science of the University of 
Wisconsin-Milwaukee invites nominations 
and applications for the position of a Distin¬ 
guished/Chaired Professor in Computer Sci¬ 
ence. It is expected that candidates will have 
an outstanding reputation in research, a 
strong interest in teaching and a commitment 
to the development of Computer Science at 
the University. It is also desirable that the 
selected candidate would develop an inter¬ 
action with the local industry. The main in¬ 
terests of the candidates should be in one of 
the following areas: Artificial Intelligence, 
Computer Architecture, Computer Systems, 
and Software Engineering. Salary and other 
benefits are competitive. 

The Department offers undergraduate and 
graduate programs in Electrical Engineering 
as well as Computer Science. The Computer 
Science faculty strength is 13 and is expected 
to grow. The current areas of faculty re¬ 
search strengths include: Data Security, 
Architecture, Parallel and Distributed Com¬ 
putation, Theory, Artificial Intelligence, Data 
Bases and Software Engineering. The De¬ 
partment serves about 200 undergraduate 
and over 100 graduate students at the M.S. 
and Ph.D. level in Computer Science. The 
University is located near the shores of Lake 
Michigan, and is close to beautiful parks and 
pleasant residential areas. 

Nominations/applications should be sent 
with the names of at least five references to: 
Professor K. Vairavan 
Chairperson-Computer Science 
Department of Electrical Engineering 
and Computer Science 
University of Wisconsin-Milwaukee 
The University of Wisconsin-Milwaukee is 
an equal opportunity/affirmative action 
employer. 


GEORGIA INSTITUTE 
OF TECHNOLOGY 
School of Information and 
Computer Science 

The School of Information and Computer 
Science invites applications for faculty posi¬ 
tions at all levels. Applicants should have a 
commitment to teaching and a record of out¬ 
standing research accomplishments. Appli¬ 
cants who expect to receive a Ph.D. degree 
by Fall 1989 and who show high potential for 
research as well as a commitment to teaching 
are also invited. 

The School seeks applicants to strengthen 
its capabilities in all areas of computer sci¬ 
ence. Very competitive salaries are offered. 

The School has 30 faculty members and 
anticipates further faculty growth. Its educa¬ 
tional activities include an undergraduate 
program accredited by the Computing Sci¬ 
ences Accreditation Board, Inc., a Masters 
program with 150 students and a Ph.D. pro¬ 
gram with over 70 students. Well equipped 
laboratories support research and education. 


High-speed local area networks interconnect 
all major campus laboratories and provide 
access to national networks. 

The School is in the second year of a five 
year Coordinated Experimental Research 
grant from the National Science Foundation. 
This grant is funding acquisition of hardware 
and development of software to suport ex¬ 
perimental work in parallel and distributed 
computing. 

Georgia Tech is located in Atlanta, which 
experiences a mild sunbelt climate. It is the 
center of commerce in the Southeast, offer¬ 
ing a diverse economy and good employ¬ 
ment opportunities in all professional areas. 
Atlanta offers good cultural and recreational 
opportunities, extremely attractive residen¬ 
tial neighborhoods, and affordable housing. 

Candidates should send complete re¬ 
sumes and names of at least three references 
to: Chairman, Faculty Search Committee; 
School of Information and Computer Sci¬ 
ence; Georgia Institute of Technology; 
Atlanta, Georgia 30332. 

Georgia Tech is an equal opportunity 
employer. 


THE UNIVERSITY OF ARIZONA 

The Department of Computer Science at 
the University of Arizona invites applications 
for faculty positions at all ranks to begin in 
August, 1989. Applicants must have a doc¬ 
torate in Computer Science or a closely 
related field. Applicants for senior positions 
should have made substantial research con¬ 
tributions to the field, while applicants for 
junior positions should show promise of 
future excellence. 

The Department of Computer Science at 
Arizona emphasizes excellence in research 
and teaching. There are currently 12 faculty 
members, with plans to expand over the 
next few years as the department institutes a 
selective undergraduate major. Research is 
currently conducted in a variety of areas in¬ 
cluding programming languages, software 
systems, parallel and distributed computing, 
logic programming, and theory of computa¬ 
tion. Qualified individuals working in these 
areas—as well as other areas such as artifical 
intelligence, computer architecture, scientific 
computation, and performance analysis- 
are encouraged to apply. 

The research program is supported by 
numerous grants to individual faculty as well 
as a department-wide NSF grant for Coor¬ 
dinated Experimental Research (CER). 
Computational facilities include a VAX 
8650, dozens of Sun workstations, an Intel 
iPSC Hypercube, and an HP 9000 graphics 
workstation. Also available are high- 
resolution color terminals, microcomputers, 
laser printers, and a phototypesetter. A 
soon-to-expand instructional laboratory con¬ 
tains two VAX ll/785s. 

Send a complete resume and the names 
of at least three references to Richard D. 
Schlichting, Faculty Recruiting Committee 
Chairman, Department of Computer Sci¬ 
ence, The University of Arizona, Tucson, AZ 
85721. Applications will be reviewed begin¬ 
ning January 15. 1989, but the positions will 
remain open until filled. The University of 
Arizona is an equal opportunity/affirmative 
action employer. 


WORCESTER POLYTECHNIC 
INSTITUTE 

The Computer Science Department in¬ 
vites applications for tenure track faculty 
positions at all levels. Candidates from all 
areas of computer science will be con¬ 
sidered; however preference will be given to 
candidates with expertise in theoretical 
aspects of computer science and computer 
architecture. Candidates should have a 
Ph.D. in Computer Science and a strong in¬ 
terest in both research and teaching. 

Worcester Polytechnic Institute empha¬ 
sizes quality in the undergraduate learning 
experience and is committed to an innova¬ 
tive project-oriented teaching environment. 
The undergraduate computer science degree 
is accredited by the Computer Sciences Ac¬ 
creditation Board. 

The current goal of the Institute is to 
enhance our graduate program and improve 
research activities. The department seeks 
qualified candidates who will help us achieve 
these objectives. WPI is located close to the 
center of the Massachusetts minicomputer 
industry and excellent opportunities exist for 
cooperative research and consulting. 

The Department has 12 full-time faculty 
with 170 undergraduates and 50 full-time 
and 100 part-time graduate students in our 
M.S. and Ph.D. programs. Department 
equipment includes an Encore MultiMax, 
four VAX 750s, an AT&T 3B-15, seven 
Sun workstations, and more than 80 PCs 
(both UNIX and MS-DOS based). Most of 
this equipment is interconnected via Ether¬ 
net. The Institute is completing the installa¬ 
tion of a campus-wide telecommunication 
system which will provide complete connec¬ 
tivity throughout the campus. A new Infor¬ 
mation Science Building is currently under 
construction, and we plan to move into our 
new facilities during the 1989 fall semester. 

Located 45 miles west of Boston, Wor¬ 
cester is a city of 180,000 people. There are 
seven colleges and universities in greater 
Worcester, and Worcester offers a rich varie¬ 
ty of cultural activities. 

Please send a resume to Robert Kinicki, 
Department Head, Department of Com¬ 
puter Science, WPI, Worcester, MA 01609. 

WPI is an Equal Opportunity/Affirmative 
Action Employer. 


TRINITY COLLEGE 

The Department of Engineering and Com¬ 
puter Science invites applications from out¬ 
standing candidates for a tenure-track position 
at the Assistant Professor-level commencing 
September, 1989, in the areas of FLUID 
MECHANICS/HEAT TRANSFER or 
ROBOTICS/CONTROLS. Experimental 
background highly desirable. The position in¬ 
volves graduate and undergraduate instruc¬ 
tion and research, and a doctoral degree is a 
prerequisite. We are interested in receiving 
applications from qualified women and 
minorities. Trinity College is an equal oppor¬ 
tunity/affirmative action employer. Please 
send resume to Professor Joseph D. Bron¬ 
zino, Chairman, ECS Department. Trinity 
College, Hartford, CT 06106. Applications 
will be accepted until February 15, 1989. 
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UNIVERSITY OF HOUSTON 

Applications are invited for tenure track 
faculty positions in the Department of Com¬ 
puter Science starting September 1989. 
Areas of special interest include but not 
limited to artificial intelligence, computer ar¬ 
chitecture, computer graphics, computer 
networks, operating systems, programming 
languages and software engineering. Rank 
and salary are open and competitive. The 
Department is interested in expanding its 
research program and particularly welcome 
applicants for senior positions. Applicants 
should have a Ph D. in Computer Science or 
a closely related area, and a strong commit¬ 
ment to research and teaching. Candidates 
for senior positions should also have a 
distinguished research record. The Depart¬ 
ment offers Ph.D., M.S., and B.S. in Com¬ 
puter Science. Departmental research 
facilities include a network of SUN Worksta¬ 
tions, VAX 11/780 and VAX 11/730’s, a 
network of AT + T 3B20 and 3B2’s and ac¬ 
cess to other computing facilities in the 
University Computer Center as well as 
supercomputers via remote access ter¬ 
minals. Send resume and names of profes¬ 
sional references to Dr. Willis King, Chair¬ 
man, Department of Computer Science, 
University of Houston, Houston, Texas 
77204-3475. An Equal Opportunity/ 
Affirmative Action Employer. 


WASHINGTON UNIVERSITY 
St. Louis 

Regular Faculty Positions in 
Computer Science 

The Department of Computer Science at 
Washington University in St. Louis is ex¬ 
panding its research program and invites ap¬ 
plications for regular (tenure-track) faculty 
positions at the Assistant, Associate and Full 
Professor levels. Applicants should hold the 
Ph D. or D.Sc. degree in Computer Science 
and have a strong commitment to and re¬ 
cord of accomplishment in research. 

The Department of Computer Science 
has a well-respected undergraduate pro¬ 
gram and a growing graduate program. Re¬ 
search activities have flourished in recent 
years and have three foci: concurrent 
systems, communications systems, and in¬ 
telligent computer systems, with an em¬ 
phasis on the use of visualization as a tool in 
each case. Support for these research pro¬ 
grams is from NSF, NIH, ONR and a large 
number of industrial sponsors. 

Current departmental research in concur¬ 
rent systems includes the formal foundations 
of concurrent computation, programming 
languages and methodologies for the design 
of concurrent systems, system interconnec¬ 
tion networks and parallel architectures and 
algorithms. The department is also engaged 
in research on the design of fast packet¬ 
switching systems capable of a variety of ap¬ 
plications (including voice, data and video). 
Of particular interest are candidates with 
backgrounds in communications systems ar¬ 
chitecture, communications software, or 
performance analysis. In the area of intelli¬ 
gent computer systems, present research 


projects include computer vision, image pro¬ 
cessing, visual programming, speech recog¬ 
nition, expert systems and deductive data¬ 
bases. Individuals with backgrounds in any 
of these areas are encouraged to apply. 

Qualified applicants may send a vita and 
names and addresses of at least three refer¬ 
ences to Dr. Jerome R. Cox, Jr., Chairman, 
Department of Computer Science, Wash¬ 
ington University, Campus Box 1045, St. 
Louis, Missouri 63130. 

Applications are requested by February 1, 
1989. Washington University is an equal op¬ 
portunity/affirmative action employer. 


UNIVERSITY OF PITTSBURGH 

Department of Computer Science 

The Department of Computer Science 
has entered a period of substantial growth 
and invites applications for four tenure track 
faculty positions to be filled by June, 1989 or 
as soon as possible. Although we are pri¬ 
marily seeking candidates at the assistant 
professor level, we will also consider can¬ 
didates for appointment at more senior 
ranks, commensurate with demonstrated 
scholarly achievements. Responsibilities in¬ 
clude research, supervision of graduate stu¬ 
dent research (Ph.D. and M.S.), and gradu¬ 
ate and undergraduate teaching. Candidates 
should have a Ph.D. in computer science or 
in a closely related field and a strong interest 
in both research and teaching. All areas of 
specialization in computer science will be 
considered, with preference given to pro¬ 
gramming languages, software engineering, 
operating systems and artificial intelligence. 

The Department currently has twenty-one 
full-time faculty members and supports 
strong graduate and undergraduate pro¬ 
grams. Departmental resources include an 
excellent research library and numerous 
computing facilities including a network of 
SUN and Xerox 1100-series (Dandelion) 
workstations, a VAX 11/780 (under BSD 
UNIX), a variety of micro-computers, and 
several graphics systems. The research 
systems are accessible via the Department’s 
Ethernet-compatible LAN. Convenient ac¬ 
cess is also provided to the extensive general 
computer facilities of the University as well as 
to other networks (e.g., ARPANET, 
CSNET). The Department operates the 
Center for Parallel, Distributed and In¬ 
telligent Systems (CPDIS) to provide an en¬ 
vironment for innovative research in com¬ 
puter science. Since the University of Pitts¬ 
burgh is a founding member of the Pittsburgh 
Supercomputing Center and an affiliate 
member of the Software Engineering Insti¬ 
tute, the Department of Computer Science 
has access to the Cray XMP/48 of PSC and 
the software engineering expertise at SEI. 

Please send your resume to: Dr. Mary 
Lou Soffa, Chair of Faculty Search, Depart¬ 
ment of Computer Science, University of 
Pittsburgh, Pittsburgh, PA 15260. 

Pitt is an equal opportunity/affirmative ac¬ 
tion employer and especially encourages 
women and members of ethnic minorities to 
apply. 


TEXAS A&M UNIVERSITY 

Department of Computer Science 

Applications are invited for faculty posi¬ 
tions at the Assistant, Associate or Full Pro¬ 
fessor level. We are particularly interested in 
faculty in the areas of computer architecture, 
programming languages, artificial intelli¬ 
gence , and real time systems, but candidates 
from all areas of computer science will be 
considered. In addition to regular faculty 
positions, an endowed chair in computer ar¬ 
chitecture is to be filled. 

The Department of Computer Science 
has 21 full-time senior faculty members and 
additional teaching staff. There is a tradition 
of quality instruction at the B.S., M.S. and 
Ph.D. levels. The University is committed to 
a major expansion of the Computer Science 
Department, and several positions are 
available. 

Computer Science at Texas A&M Univer¬ 
sity has recently added a program in com¬ 
puter engineering. The department is 
located in the College of Engineering, which 
is one of the nation’s largest with approx¬ 
imately 9,000 students. Computer Science 
is expanding to become one of the larger and 
more comprehensive departments in the 
country. 

We seek excellence in research. Texas 
A&M will provide superior instructional and 
research facilities for its Computer Science 
faculty. The University has the internal 
resources to achieve this goal. Applicants at 
the assistant professor level should show 
substantial promise for research and teach¬ 
ing. Applicants at the higher levels should 
show a strong record of research achieve¬ 
ment. Ability in teaching graduates and 
under-graduates is also essential. Applicants 
should have a doctoral degree or its equiva¬ 
lent. Applicants should submit a resume and 
three references to Donald K. Friesen, 
Chairman, Faculty Search Committee, 
Computer Science Department, Texas 
A&M University, College Station, TX 
77843-3112. 

Texas A&M University is an equal oppor¬ 
tunity/affirmative action employer. 


THE UNIVERSITY OF TEXAS 
AT ARLINGTON 

The Department of Computer Science 
Engineering at The University of Texas at 
Arlington invite'syo'ur application for tenure- 
track or visiting faculty positions in all areas of 
computer science and computer engineer¬ 
ing. Rank is open. An earned doctorate or 
equivalent and commitment to teaching and 
scholarly research is required. Openings are 
expected for September 1989. Applications 
received prior to March 1, 1989 will receive 
full consideration. Interested persons should 
send a resume to Bill D. Carroll, Professor 
and Chairperson, Computer Science Engi¬ 
neering Department, P.O. Box 19015, The 
University of Texas at Arlington, Arlington, 
TX 76019. Phone 817-273-3785. 

The University of Texas at Arlington is an 
Equal Opportunity Affirmative Action 
Employer. 
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UNIVERSITY OF 
SOUTHERN CALIFORNIA 
Chair, Computer Science 

The Computer Science Department of the 
School of Engineering, University of South¬ 
ern California (USC), seeks a distinguished 
computer scientist with the vision and skill to 
lead a strong department and further strength¬ 
en it. The School of Engineering, with 170 
faculty and 4,300 students, ranks 6th in the 
nation in sponsored research expenditures. 
The Computer Science Department has a 
full time faculty of 22, and a student body of 
125 Ph.D. students, 250 M.S. candidates, 
and 200 undergraduates. The departmental 
research budget currently is $3M per year. 
Faculty research interests encompass the 
traditional areas of computer science, plus 
interdisciplinary, emerging fields such as 
robotics and neural computation. Comput¬ 
ing research support is provided by a large 
network of modern workstations, and vari¬ 
ous supercomputers are available through 
the network. More than 100 SUN work¬ 
stations are used for teaching. The depart¬ 
ment maintains close ties with the Electrical 
Engineering Department which has a strong 
Computer Engineering Group of 16 faculty, 
and with the Information Sciences Institute 
(ISI), an off-campus research facility of the 
School of Engineering. ISI’s staff of 200 con¬ 
ducts research on a broad spectrum of com¬ 
puter science topics. Southern California has 
the highest industrial production in the na¬ 
tion. Opportunities for industry/university 
collaboration are excellent because much of 
the local industry is high-tech and computa¬ 
tionally oriented. 

Please send nominations and applications 
to: 

Professor Aristides Requicha 
Chair, Search Committee 
Computer Science Department 
University of Southern California 
Los Angeles, CA 90089-0782 
Telephone: (213) 743-3805 
Net Mail: requicha@lipari.usc.edu 
Applications should include a resume and 
a list of professional references. USC is an 
equal opportunity employer. 


UNIVERSITY OF COLORADO 
AT BOULDER 

Department of Computer Science 

We invite applications for a faculty posi¬ 
tion in the area of software engineering. The 
rank for this position is open: applicants at 
the senior ranks must have a distinguished 
research record, with a demonstrated ability 
to lead major research projects. We also in¬ 
vite applications for four other positions in all 
research areas; preference is at the assistant 
professor level but candidates at all levels will 
be considered. Areas of particular interest in¬ 
clude: databases; parallel and numerical 
computation; and computing systems, es¬ 
pecially networks and distributed systems. 
Applicants must have a strong commitment 
to high standards of excellence in academic 
research and teaching. 

The Department has a faculty of 20 and 
160 graduate students. It has strong research 
programs in parallel and distributed com¬ 


putation, numerical computation, artificial 
intelligence, systems and software, data¬ 
bases, and theoretical computer science. 
The computing environment includes Vax- 
class mainframes, SUN-class workstations, 
Symbolics workstations, shared and local 
memory multiprocessors including an Intel 
Hypercube, Encore and Sequent multipro¬ 
cessors, and an Alliant FX/8. A number of 
research activities in distributed computation 
are supported by an NSF-funded CER 
award. The Department is a principal partici¬ 
pant in the University’s Center for Applied 
Parallel Processing which has a broad inter¬ 
disciplinary research program in large scale 
scientific computation and operates a Think¬ 
ing Machines CM2. There is also a satellite 
link to the supercomputing facility at the 
John Von Neumann Center in Princeton. 

Applicants should send a current curricu¬ 
lum vita to Professor Lloyd Fosdick, Chair¬ 
man, Department of Computer Science, 
Campus Box 430, University of Colorado, 
Boulder, CO 80309-0430. Applications are 
due by February 15, 1989. Late applications 
will be considered for any positions remain¬ 
ing unfilled on March 15, 1989. 

The University of Colorado at Boulder has 
a strong institutional commitment to the prin¬ 
ciple of diversity in all areas. In that spirit, we 
are particularly interested in receiving appli¬ 
cations from women, ethnic minorities and 
disabled individuals. 


CLEMSON UNIVERSITY 
Director 

Computer Communications 
Systems Center 

Clemson University seeks candidates for 
Director, Computer Communication Sys¬ 
tems Center. The state Commission of 
Higher Education recently approved the 
establishment of the Center as a joint effort of 
the College of Engineering and College of 
Sciences at Clemson University to bring 
together and extend existing projects and ac¬ 
tivities. Participating departments currently 
include Computer Science, Electrical and 
Computer Engineering, Industrial Engineer¬ 
ing and Mathematical Sciences. Involve¬ 
ment of other departments and colleges is 
anticipated. The Center serves as the focus 
of graduate study and research in the areas 
of computer communication networks, deci¬ 
sion processes, and system optimization and 
control. Industrial firms and government 
agencies involved in these areas also par¬ 
ticipate in Center activities as affiliate 
members. 

Applicants should have industrial and/or 
academic experience which would enable 
them to interact effectively with the Center’s 
commercial and academic participants. Re¬ 
sponsibilities include academic and research 
leadership, fiscal management, and industrial 
relations. The successful candidate would be 
expected to hold a faculty appointment in one 
of the participating academic departments. 

Interested individuals should send a letter 
of application and a resume to: Dr. Wayne 
Madison, Chairman, CCSC Search Com¬ 
mittee, Computer Science Department, 
Clemson University, Clemson, S.C. 
29634-1906 by February 17, 1989. Clem¬ 
son University is an equal opportunity/affir¬ 
mative action employer. 


UNIVERSITY OF TULSA 

The Department of Mathematical and 
Computer Sciences at the University of Tulsa 
invites applications for tenure track positions 
in Computer Science at junior and senior 
ranks to begin in September of 1989. Re¬ 
sponsibilities include teaching 6 hours per 
semester at the undergraduate and graduate 
level, continuing scholarly activity, and pur¬ 
suit of extramural funding. Minimum qualifi¬ 
cations are a Ph.D. in computer science or a 
related discipline and a strong commitment 
to teaching and research. Candidates with 
research specialties in Parallel and Scientific 
Computing, Computer Graphics, and Knowl¬ 
edge Based Systems are of particular interest; 
however, all research areas will be considered. 

The Department of Mathematical and 
Computer Sciences offers the Ph.D. degree 
in Computer Science; has a VAX 11/750, 
two Micro VAX II systems, and ten Sun 3 
systems for faculty and student research; and 
is a member of NSFnet and BITnet. 

Applications will be evaluated beginning 
February 1, 1989. The position will be con¬ 
sidered open until filled. Send vita, tran¬ 
scripts, and three letters of reference to: 
William A. Coberly, Chairman; Mathemati¬ 
cal and Computer Sciences; University of 
Tulsa; 600 S. College; Tulsa, OK 74104. 
The University of Tulsa has an Equal Oppor¬ 
tunity/Affirmative Action Program for stu¬ 
dents and employees. 


UNIVERSITY OF CALIFORNIA 
BERKELEY 

THE UNIVERSITY OF CALIFORNIA 
AT BERKELEY invites applications for 
visiting professor and lecturer positions in 
COMPUTER SCIENCE. Visiting professor 
and lecturer positions are normally one-year 
appointments. 

Research facilities include several main¬ 
frame computers (VAX 8600 and similar), 
80 general-purpose networked workstations 
(SUN and similar), numerous LISP (Sym¬ 
bolics, TI, Xerox) workstations and access to 
an on-site IBM 3090 and Cray-XMP. In¬ 
structional hardware includes numerous 
SUN workstations. VAX systems. Macin¬ 
toshes, PC’s and mainframes. 

Visiting professor positions are often filled 
by persons on sabbatical leave from other 
universities, and lecturer positions are often 
filled by persons on temporary leave from 
research laboratories. Such experience is not 
a requirement, however. Applicants with a 
doctoral degree in Computer Science (com¬ 
plete or nearly complete) are preferred. The 
successful candidate must be able to teach 
core undergraduate courses and may also 
have an opportunity to teach graduate 
courses. Send resume, and the names of 
three references by March 1, 1989, to the 
address below. 

Professor Richard Fateman 
Associate Chairman for Computer Science 
Department of Electrical Engineering 
and Computer Sciences 
University of California 
Berkeley, CA 94720. 

The University of California is an Equal 
Opportunity, Affirmative Action Employer. 
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THE UNIVERSITY OF TENNESSEE 

Department of Computer Science 

Knoxville, Tennessee 37996-1301 

The Department of Computer Science in¬ 
vites applications for tenure-track positions at 
the rank of Professor beginning Spring 1989. 
A strong research record in the areas of com¬ 
puter graphics, networking, or operating sys¬ 
tems is sought but all major fields in com¬ 
puter science may be considered. Experi¬ 
ence directing doctoral students is especially 
important. Tenure-track positions for Associ¬ 
ate and Assistant Professors are also open. 
Applicants for Associate Professor should 
have a strong research record, preferably in 
the above-named areas; experience direct¬ 
ing doctoral students is desirable. Applicants 
for Assistant Professor should have a strong 
interest in research, preferably in the above- 
named areas. Applicants for all positions 
should have a doctoral degree in computer 
science or a related area. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. The University operates 
an IBM 3090 and a large VAX cluster. 
CRAY, HYPERCUBE, SEQUENT and 
other machines are available via high speed 
link with Oak Ridge National Laboratory. 

You can respond to straight@utkvx.utk. 
edu. The mailing address is Department of 
Computer Science, 107 Ayres Hall, The 
University of Tennessee, Knoxville TN 
37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLE IX/SECTION 504 employer. 


CASE INSTITUTE OF TECHNOLOGY 

Case Western Reserve University 

We invite applications for tenure track 
faculty positions at all levels. Candidates 
from all research areas will be considered, 
but the thrust research areas in the Depart¬ 
ment are VLSI systems and design automa¬ 
tion, applied artificial intelligence and logic 
programming, database design and systems, 
and software systems and design environ¬ 
ments, with additional faculty in computer 
graphics and networks/distributed systems. 
Candidates should have a Ph.D. in com¬ 
puter science or computer engineering or 
closely allied fields; competitive salaries will 
be offered to attract the best candidates. 

CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has a faculty of 13 and 
growing, and a graduate student body of 
140 students, 50 of which are in the Ph.D. 
program. Departmental facilities are based 
upon an ethernet local area network, con¬ 
nected to INTERNET, which supports a 


UNIX operating system and about 30 SUN 
workstations, color graphics display ter¬ 
minals, together with several printers. In ad¬ 
dition, faculty and students participating in 
the Center for Automation and Intelligent 
Systems Research have access to the 
Center’s VAX-11/782 and workstations. 

The Department recently acquired the 
Nord Professorship, supported by a dona¬ 
tion of one and a half million dollars, for 
which we invite distinguished senior faculty 
applicants. This position will provide addi¬ 
tional funds for travel, graduate student sup¬ 
port and equipment. 

Applicants should submit their curriculum 
vitae and names of at least three references 
to: Lee J. White, Chairman, Department of 
Computer Engineering and Science, Case 
Western Reserve University, Cleveland, 
Ohio 44106; INTERNET: leew@alpha.ces. 
cwru.edu; candidates with previous aca¬ 
demic experience may wish to provide at 
most three reprints of their most important 
publications. 

An equal employment and affirmative ac¬ 
tion employer. 


UNIVERSITY OF MARYLAND 

The Electrical Engineering Department of 
the University of Maryland College Park has 
openings for regular faculty positions in com¬ 
puter engineering. Candidates for the rank 
of Assistant Professor should have a high 
potential for both teaching and research. 
Candidates for the rank of Associate Pro¬ 
fessor and Full Professor should have distin¬ 
guished records in research and a strong 
interest in educational programs. The 
department conducts research and educa¬ 
tional programs in several areas of computer 
engineering. Although applications in all 
areas of computer engineering will be con¬ 
sidered, operating systems, computer secu¬ 
rity, architectures for parallel computing, and 
VLSI are currently the highest priority areas 
for adding new faculty. Application, includ¬ 
ing resume, list of publications, list of refer¬ 
ences, identification of technical area for 
which the candidate wishes to be con¬ 
sidered, should be sent to Dr. William W. 
Destler, Chairman, Electrical Engineering 
Department, University of Maryland, Col¬ 
lege Park, Maryland 20742. The University 
of Maryland is an equal opportunity, affir¬ 
mative action employer. 


UNIVERSITY OF NEW ORLEANS 
Professorships in Computer Science 

We invite applications for tenure-track 
positions in the Computer Science Depart¬ 
ment at the University of New Orleans. Ours 
is a rapidly-developing program with ap¬ 
proximately 400 majors at the second- 
largest public university in Louisiana. We 
also offer graduate study through the 
Master’s level in a cooperative program with 
the Department of Mathematics. Our De¬ 
partment numbers 11 full-time faculty with 
good prospects for continued expansion for 
several years. Our undergraduate program 


has been accredited by the Computing Sci¬ 
ences Accreditation Board, and was also 
singled out for excellence by the Louisiana 
Board of Regents in the past year. Only two 
universities in Louisiana have received both 
of these recognitions. 

University computing facilities include a 
network of four VAX 8600’s running VMS 
4.5 and DECNET, and approximately 150 
Z-100 (MS-DOS compatible) 10 MB micro¬ 
computers which serve as the principal 
workstations on campus. There is also a 
campus-wide Ethernet. Departmental facili¬ 
ties include a Gould 6040/Berkeley 4.3bsd 
Departmental computing system, a Sym¬ 
bolics 3640 LISP machine, and several Sun 
workstations, as well as a nurriber of 
microcomputers and a PDP-11. We have 
now completed a purchase of a large 
number of advanced workstations to com¬ 
plement the existing facilities, including one 
for each faculty member. We are also a 
member of CSNET. Ada is used as the pri¬ 
mary programming language in under¬ 
graduate teaching. 

Candidates will be considered for both 
junior and senior positions. Candidates 
should have a doctorate in Computer Sci¬ 
ence or in a related field, and should be 
interested in a career where teaching excel¬ 
lence is rewarded and research encouraged. 
Our primary objective is for faculty in the 
areas of operating systems, database man¬ 
agement systems, and software engineering; 
candidates whose specialties are in other 
branches of computer science will only be 
considered under exceptional circumstances. 

Please send your resume and three refer¬ 
ences before March 15, 1989 to Wayne Pat¬ 
terson , Chairman, Department of Computer 
Science, University of New Orleans, New 
Orleans, LA 70148. (Phone: 504-286- 
6594.) Inquiries may also be directed via Bit- 
Net to rwpcs@uno or via CSNet to wpatters 
@uno. Review of the applications will begin 
upon their receipt. Women and minorities 
are especially encouraged to apply. The 
University of New Orleans is an Equal Op¬ 
portunity/ Affirmative Action Employer. 


UNIVERSITY OF WASHINGTON 

The University of Washington seeks can¬ 
didates for tenure-track faculty appointments 
in computer science/engineering starting in 
the 1989-90 academic year. Applications 
from outstanding individuals in all areas 
of computer science/engineering wilT be 
considered. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. Any appointment 
should bring significant new research 
strength to the University. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to: Computer Science/Engi¬ 
neering Faculty Recruiting Committee, 
FR-35, University of Washington, Seattle, 
WA 98195. 

The University of Washington is an Affir¬ 
mative Action/Equal Opportunity Employer. 
The Ph.D. is required for these positions. 
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MEMPHIS STATE UNIVERSITY 
Department of Mathematical Sciences 

The Department of Mathematical Sci¬ 
ences invites applications for anticipated 
tenure track positions for 1989. The Depart¬ 
ment offers degrees at all levels including the 
Ph.D. and provides a very favorable re¬ 
search environment in terms of library and 
computing facilities (including a symbolic In¬ 
tel Hypercube), teaching load, and travel op¬ 
portunities. Preferred research areas in com¬ 
puter science include algorithms, parallel 
and distributive processing, artificial in¬ 
telligence/cognitive science, software devel¬ 
opment, network design and analysis, data 
communications, and theory. Preferred re¬ 
search areas in statistics include time series, 
biostatistics, stochastic models, and applied 
statistics. Preferred research areas in mathe¬ 
matics include applied mathematics, numer¬ 
ical analysis, dynamical systems, graph 
theory and combinatorics, analysis, differen¬ 
tial equations, and related areas. Applicants 
must have a Ph.D. by September 1, 1989, 
and a strong potential for excellence in 
teaching and research. 

Selection will begin on February 10, 
1989. Applications will continue to be ac¬ 
cepted until all positions are filled. Women 
and Minorities are strongly urged to apply. 
Successful candidates must meet the Im¬ 
migration Reform Act criteria of 1986. Ap¬ 
plicants should submit a resume and direct 
three letters of reference to: 

Ralph Faudree, Chair 
Department of Mathematical Sciences 
Memphis State University 
Memphis, TN 38152 
An Equal Opportunity/Affirmative Action 
Employer. 


AUBURN UNIVERSITY 

Department of Computer Science 
and Engineering 

Applications are invited for tenure-track 
faculty positions at the Assistant Professor 
level. Applications at the Associate or Full 
Professor levels will also be considered. A 
Ph.D. in Computer Science, Computer 
Engineering, Electrical Engineering or a 
closely related discipline is required. Prefer¬ 
red areas of interest include but are not 
limited to Computer Architecture, Data Base 
Systems, and Operating Systems. Positions 
are open for the 88-89 academic year. 
Salary and faculty rank are competitive 
depending upon experience and qualifica¬ 
tions. Responsibilities include teaching at the 
graduate and undergraduate levels and 
building the on-going research program. The 
department offers Bachelor’s degrees in 
Computer Science and Computer Engineer¬ 
ing as well as the M.S. and Ph.D. An 
outstanding research program has been 
established in the above subdisciplines. Ap¬ 
plicants should submit a detailed resume and 
the names of three references to: Chair of the 
Search Committee, Department of Compu¬ 
ter Science and Engineering, Auburn Uni¬ 
versity, AL 36849-5347. Minorities and 
women are encouraged to apply. Auburn 
University is an Equal Opportunity/Affir¬ 
mative Action Employer. 


OREGON STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science in¬ 
vites qualified applicants for tenure-track 
Assistant, Associate and Full Professorships. 
Specialization in programming languages 
and systems, information-based systems, 
software engineering, theoretical computer 
science, computer architecture, artificial in¬ 
telligence or computer graphics is desirable 
but all qualified applicants will be considered. 
Applicants should have completed or expect 
to complete all requirements for a Ph.D. in 
computer science or a closely related field 
and should have demonstrated research and 
teaching potential. Candidates for senior 
positions should have an established re¬ 
search reputation. Review of applications 
will begin November 1, 1988, and will con¬ 
tinue until the positions are filled. Please 
send resume, including the names of three 
references, to: Walter G. Rudd, Chairman, 
Department of Computer Science, Oregon 
State University, Corvallis, OR 97331. 

Oregon State University is an equal op¬ 
portunity affirmative action employer and 
complies with Section 504 of the Rehabilita¬ 
tion Act of 1973. OSU has a policy of being 
responsive to the needs of dual-career 
couples. 


UNIVERSITY OF MASSACHUSETTS 
AMHERST 

Faculty and Research Scientist 
Positions 

The Department of Computer and Infor¬ 
mation Science invites applications for 
tenure-track faculty positions and non¬ 
tenure-track research scientist positions at all 
levels in all areas of computer science. Ap¬ 
plicants should have a Ph D. in computer 
science or related area and should show 
evidence of exceptional research promise. 
Senior level candidates should have a record 
of distinguished research. Salary is commen¬ 
surate with education and experience. Our 
department has grown substantially over the 
past five years and currently has 28 full-time 
faculty. 18 research scientists, and 200 
graduate students. Continued growth is ex¬ 
pected over the next five years. We have 
ongoing research projects in robotics vision. 
natural language processing, expert systems, 
distributed processing, database systems, in¬ 
formation retrieval, software development, 
programming languages, computer net¬ 
works. office automation, intelligent user in¬ 
terfaces, parallel computation, and com¬ 
puter architecture. The department is the 
recipient of a CER award from NSF and a 
URI award from ONR. To support our re¬ 
search. we have a 200-mode network, in¬ 
cluding numerous large VAX and Sequent 
systems, a variety of graphics devices. LISP 
machines, and workstations. Send vita, 
along with the names of four references to: 
Dr. Janice Cuny. COINS Department. 
Lederle Graduate Research Center. Univer¬ 
sity of Massachusetts. Amherst, MA 01003, 
by March 1. 1989. An Affirmative Action/ 
Equal Opportunity Employer. 


AUBURN UNIVERSITY 
Department Head 
Computer Science and 
Engineering Department 

The Computer Science and Engineering 
Department of Auburn University, Auburn, 
Alabama, invites applications for the position 
of department head. This position also in¬ 
cludes appointment at a professorial rank in 
the College of Engineering. Qualified per¬ 
sons with a solid record of achievement and 
the desire to lead a growing, research-ori¬ 
ented department are encouraged to apply. 

The Department has eleven full-time 
faculty members and offers the Bachelor’s 
degree in both Computer Science and Com¬ 
puter Engineering, as well as the M.S. and 
Ph.D. degrees. The undergraduate program 
is both ABET and CSAB accredited. Depart¬ 
mental equipment includes a VAX 11/780, 
MICROVAX II, a Network of TI Explorers, 
Apollo Workstation, and an array of micro¬ 
computers. Campus-wide facilities include 
an IBM 3083, VAX 11/785, VAX 8200, 
VAX 8250 and a host of IBM PC’s. In addi¬ 
tion, Auburn is a member of the Alabama 
Supercomputer Network which includes a 
CRAY X-MP/24. 

The quality of life available in the Auburn 
Community is superb; it is a college-town at¬ 
mosphere and the city is strategically located 
close to several large metropolitan centers 
such as Atlanta and Montgomery. Salary is 
commensurate with education and experi¬ 
ence. Nominations and applications should 
be sent to J. David Irwin, Chairman, CSE 
Department Head Search Committee, Elec¬ 
trical Engineering Department, Auburn 
University, AL 36849-5201. Minorities and 
women are encouraged to apply. Auburn 
University is an equal opportunity and affir¬ 
mative action employer. 


UNION COLLEGE 
Faculty Position 

The Department of Electrical Engineering 
and Computer Science invites applications 
for the position of Assistant/Associate Pro¬ 
fessor in Computer Science. Union offers 
both the B.S. and M.S. degrees in Com¬ 
puter Science. 

An applicant should have a doctorate with 
major emphasis in C.S. Good teaching is ex¬ 
pected and supported. The College main¬ 
tains regular funds for research and travel. 
Areas of interest include, but are not limited 
to: computational complexity, data base 
systems, algorithm design, and software 
engineering. 

Union College academic computing re¬ 
sources include a large VAX cluster running 
VMS and EUNICE, as well as the depart¬ 
ment’s computer science lab with a VAX- 
11/750 running UNIX and several graphics 
workstations. Each C.S. professor's office 
contains a high-end PC and/or MAC. 

Applicants should write to: Dr. David G. 
Hannay, Chairman, Computer Science, 
Steinmetz Hall 210, Union College, 
Schenectady, NY 12308, 

An Equal Opportunity/Affirmative Action 
Employer. 


146 


COMPUTER 










THE VIRGINIA MILITARY INSTITUTE 
Mathematics/Computer Science 

A tenure-track position beginning August, 
1989. Applicant should have a strong in¬ 
terest in teaching. VMI’s hardware includes a 
Data General MV/7800, a Burroughs A9, 
and 200 IBM PC’s. 

Preference given to an applicant with a 
Ph.D. in a computer-related field such as 
Computer Science, MIS, or Mathematics. 
Significant education or experience in CS re¬ 
quired. Duties include teaching computer 
science and mathematics. Salary and rank 
commensurate with qualifications. 

VMI is a quality undergraduate military 
college of engineering, liberal arts, and 
science, located in an attractive college 
town. Faculty wear uniforms but have no 
other assigned military duties. 

Deadline for applications is March 1, 
1989. Send resumes with at least three 
references to Thomas C. Lominac, Depart¬ 
ment of Mathematics and Computer Sci¬ 
ence, Virginia Military Institute, Lexington, 
Virginia 24450. 

AA/EEO Employer. 


WEST CHESTER UNIVERSITY 
Computer Science 

Computer Science—West Chester Uni¬ 
versity seeks applicants for a tenure-track 
computer science position in the Department 
of Mathematical Sciences beginning Sep¬ 
tember, 1989. Duties include graduate and 
undergraduate teaching and supervision of 
graduate students and research. Qualified 
applicants should possess either a Ph.D. in 
Computer Science or an M.S. in Computer 
Science coupled with industrial experience 
and/or scholarly achievements in Computer 
Science; solid record of teaching excellence 
and a demonstrated ability to carry out 
research. Preference will be given to can¬ 
didates with expertise in one or more of the 
following: Database, Graphics, Artificial In¬ 
telligence, Data Communications, and 
Computer Architecture. Send application 
and three letters of recommendation post¬ 
marked by February 15. 1989 to: Prof. 
Elaine Milito, Computer Science Search, 
Dept, of Mathematical Science, WEST 
CHESTER UNIVERSITY, West Chester, 
PA 19383. AA/EOE. Women and minor¬ 
ities are encouraged to apply. 


UNIVERSITY OF MINNESOTA, 
DULUTH 

Computer Engineering 
Department Head 

The University is seeking candidates for 
the position of Department Head of Com¬ 
puter Engineering. This will be a tenured 
position with a starting date of 9/1/89. 
Duties: faculty and staff recruitment, hiring, 
and evaluation; administering budget, cur¬ 
riculum. and facilities: teaching in a bac¬ 
calaureate program; developing and direc¬ 
ting a significant research program: and 


developing relationships with regional in¬ 
dustry. A Ph.D. in computer or electrical 
engineering is preferred, but exceptional ap¬ 
plicants with a doctorate in a related field will 
be considered. A minimum of six years of 
academic or industrial experience is essen¬ 
tial, with administrative experience prefer¬ 
red. Demonstrated evidence of effective 
teaching and communication skills appropri¬ 
ate to a faculty member is required. Minimal 
qualifications for a tenured Associate Pro¬ 
fessor are the requirements above, profes¬ 
sional distinction in research and writing, and 
demonstrated effectiveness in advising. 
Minimal qualifications for a tenured Pro¬ 
fessor are the requirements above, eight to 
ten years’ professional experience, and a na¬ 
tional reputation in research. 

The application is due on February 15, 
1989, and consists of 1) a letter of applica¬ 
tion including a discussion of experiences 
and accomplishments relevant to this posi¬ 
tion, 2) a resume, 3) the names, addresses, 
and phone numbers of three references. 
Direct applications and inquiries to Dr. Clark 
Thomborson, 145 Engineering Building, 
University of Minnesota, Duluth, MN 
55812-2496; telephone: 218-726-8256, 
email: cthombor@gw.d.umn.edu. 

The University of Minnesota is an equal 
opportunity educator and employer and 
specifically invites and encourages applica¬ 
tions from women and minorities. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tions in Institute of Information Science, 
Academia Sinica. Ph.D. in computer related 
fields required. Demonstratable research 
ability necessary. Applicants for senior posi¬ 
tions must have proven research record. All 
fields in computer science are welcome. 

The Institute offers a good research en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude 3 VAX’s, 4 SUN’s (including a SUN- 
4/260), 2 E&S workstations, a lot of small 
computers and an easily accessible ETA-10Q 
super computer at Academia Sinica. Two- 
year expansion plan will strengthen our facil¬ 
ities with an IRIS and a multi-processor 
machine. 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica. 
Taipei, Taiwan, Republic of China, e-mail 
address: WT6B0001@TWNMOE10.BIT- 
NET. FAX: (011-886-2) 782-4814. 


UNIVERSITY OF CALIFORNIA, 
SANTA BARBARA 

Electrical and Computer Engineering 

Applications are invited for 2 tenure-track 
faculty positions. Positions are open for can¬ 
didates experienced in optoelectronics/op¬ 
tical processing and in image processing or 
computer vision. The positions start at the 
rank of Assistant Professor, although higher 
level appointments are possible for in¬ 


dividuals with outstanding records. Normal¬ 
ly, completion of a doctorate is required at 
the time of the appointment. Candidates 
should have an outstanding research poten¬ 
tial or a distinguished research reputation, 
the ability to attract external research fund¬ 
ing, and a strong commitment to teaching at 
the undergraduate and graduate levels. Ap¬ 
plicants should send their resume and the 
names and addresses of four professional 
references to: Faculty Search Committee, 
Department of Electrical and Computer En¬ 
gineering, Univeristy of California, Santa 
Barbara, CA 93106, (805) 961-3821. Ap¬ 
plications will be received until the positions 
are filled. Proof of U.S. citizenship or eligibili¬ 
ty for U.S. employment will be required prior 
to employment (Immigration Reform and 
Control Act of 1986). An Equal Opportunity/ 
Affirmative Action employer. 


WEST VIRGINIA UNIVERSITY 
Electrical and Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering at West Virginia Universi¬ 
ty anticipates available faculty positions for 
1989 in the area of digital and computer 
engineering system design. Salary and rank 
will be commensurate with qualifications. 
Positions will be tenure track. Applicants 
must have the Ph.D., potential for high 
quality teaching and will be expected to in¬ 
itiate research and participate in departmental 
research programs. Curriculum vitae should 
be sent to: Dr. Ronald L. Klein, Professor 
and Chairman, Department of Electrical and 
Computer Engineering, West Virginia Uni¬ 
versity, P.O. Box 6101, Morgantown, WV 
26506-6101. Applications will be received 
and considered immediately and the search 
will continue until all available positions are 
filled. West Virginia University is an affir¬ 
mative action/equal opportunity employer 
m/f. 


RUTGERS 

The State University of New Jersey 

The Graduate School - New Brunswick at 
Rutgers University is seeking applicants for a 
Federal Aviation Administration grant- 
funded faculty position in Systems Engineer¬ 
ing with a background in Air Traffic Control 
and related issues. The position requires 
both a Ph.D. (in Systems Engineering, Com¬ 
puter Science, Aeronautics, or Operations 
Research) and demonstrated experience in 
Systems Engineering. The successful appli¬ 
cant will carry out research, develop and 
teach graduate-level courses, and advise 
graduate students. Salary and rank will be 
commensurate with qualifications and 
experience. 

Applications will be accepted until the 
position is filled. Interested persons should 
send a complete resume together with the 
names of three references to: Dr. A. Zebib, 
Rutgers University, College of Engi¬ 
neering, Piscataway, NJ 08855-0909. 
Qualified minorities and females are en¬ 
couraged to apply. Rutgers University is an 
Equal Employment Opportunity/Affirma- 
tive Action Employer. 
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SEATTLE UNIVERSITY 
Computer Science/Software 
Engineering 

Seattle University invites applications for a 
full-time, tenure-track position in its Com¬ 
puter Science/Software Engineering Depart¬ 
ment at the Assistant Professor level, to begin 
September, 1989. Applicants are expected 
to hold a doctoral degree in computer sci¬ 
ence or related area. All areas of specialty are 
considered, but preferred areas include data¬ 
base systems, computer applications, and 
software engineering. 

The Software Engineering program was 
established in 1979 and offers the Master of 
Software Engineering degree. The Com¬ 
puter Science program was established in 
1984 and offers BA and BS degrees in com¬ 
puter science. Although the position primari¬ 
ly involves teaching and other academic 
duties in the Computer Science program, 
that program is housed in a combined Com¬ 
puter Science/Software Engineering De¬ 
partment, and opportunities exist for teach¬ 
ing software engineering courses at the 
graduate level as well. 

Seattle University is one of 28 Jesuit in¬ 
stitutions of higher education in the United 
States. It is an independent, coeducational 
university located on a 52-acre campus in 
the seaport city of Seattle. Applicants are 
asked to submit a letter of application, 
resume and the names and addresses of 
three references to Dr. Everald E. Mills, 
Chair, Computer Science/Software Engi¬ 
neering Department, Seattle University, 
Seattle, WA 98122. Deadline for receipt of 
applications is March 1, 1989. Seattle 
University is an Affirmative Action/Equal 
Opportunity employer. 


UNIVERSITY OF NORTH TEXAS 
COLLEGE OF ARTS AND SCIENCES 

Department of Computer Sciences 

The Department invites applications for 
tenure-track faculty positions, pending 
budgetary approval. A Ph.D. in computer 
science or a related field and evidence of a 
strong commitment to research and teaching 
are required. Salary is competitive. Strong 
applicants in all areas of computer science 
are encouraged, but the Department has a 
special need for faculty in graphics, net¬ 
works, and software development. 

This growing department offers BS/MS/ 
Ph.D. programs to approximately 450 
undergraduate and 120 graduate majors. 
The University of North Texas is an emerg¬ 
ing national research institution with ex¬ 
cellent facilities to support both research and 
instruction in the vibrant and rapidly expand¬ 
ing Dallas-Fort Worth metropolitan area with 
over 700 regular faculty and over 24,000 
students (one third graduate students). 

Applicants should submit their resumes, 
including the names of three references, to 
Search Committee, Department of Compu¬ 
ter Sciences, P.O. Box 13886, University of 
North Texas, Denton, Texas 76203. 

UNT is an Affirmative Action/Equal Op¬ 
portunity Employer. 


UNIVERSITY OF WISCONSIN- 
PARKSIDE 

The University of Wisconsin-Parkside, 
Department of Applied Computer Science, 
invites applications for a tenure-track faculty 
position beginning in September 1989. The 
position is at the assistant professor level, but 
higher rank is possible for an outstanding 
candidate. Candidates should have a Ph.D. 
in computer science or related field with a 
strong commitment to undergraduate teach¬ 
ing and research. Current faculty interests 
are in systems software engineering, artificial 
intelligence, computer graphics and real¬ 
time computing. The University of Wisconsin- 
Parkside is one of 13 degree-granting cam¬ 
puses of the University of Wisconsin System. 
The campus is located on a beautiful site 
near Lake Michigan within the Chicago- 
Milwaukee industrial corridor. Applicants 
should send a resume, a statement concern¬ 
ing teaching and research interests and a list 
of at least three references to: Dr. George 
Perdikaris, Engineering Science Division, 
University of Wisconsin-Parkside, Kenosha, 
WI 53141-2000. Applications will be con¬ 
sidered until the position is filled. Non-US 
citizens must indicate visa status. An equal 
opportunity/affirmative action employer. 


ARIZONA STATE UNIVERSITY 
Computer Science 
Computer Engineering 

The Department of Computer Science 
seeks outstanding faculty candidates for 
research and teaching in all areas of com¬ 
puter science and computer engineering. 
Applicants should have completed or be 
completing a Ph.D. in computer science, 
computer engineering, or a closely related 
field, and must show promise of excellence 
in teaching and research. The positions are 
all tenure track; rank is open. 

Both undergraduate and graduate pro¬ 
grams through the Ph.D. are offered. The 
department is an active participant in an im¬ 
pressive alliance of high-tech businesses, the 
State, and the University building an out¬ 
standing faculty and facilities for Computer 
Science and Computer Engineering at ASU. 
Although the present facilities are only six 
years old, the department has outgrown 
them, and is slated to move into new facilities 
scheduled for completion late in 1990. 

Faculty engineering workstations are net¬ 
worked locally to DEC, IBM, Harris, Con¬ 
vex, and Honeywell mainframes, and 
through the campus broadband network to 
the university Cray XMP/14se and IBM 
3090/500E supercomputers. A major part 
of freshman/sophomore instruction is 
hosted on Macintosh’s, Intel 286/310 Xenix 
systems, and IBM PC’s. 

Please send a resume and the names of 
three references to: 

Dr. Ben M. Huey, 

Faculty Search Committee 
Department of Computer Science 
Arizona State University 
Tempe, Arizona 85287-5406. 
CSNET: huey@asu.edu 

Deadline: January 31, 1989 or until filled. 
ASU is an equal opportunity/affirmative ac¬ 
tion employer. 


UNIVERSITY OF CALIFORNIA 
AT RIVERSIDE 

Positions in Computer Science 

Applications and nominations are invited 
for tenured or tenure track positions in Com¬ 
puter Science beginning July 1, 1989 or 
later. The positions are open as to rank; can¬ 
didates at all levels, including Full Professor, 
will be considered. Ph.D. and demonstrated 
excellence in research and teaching are re¬ 
quired. All areas of Computer Science will 
be considered, including but not restricted to 
Programming Environment, Computer Sys¬ 
tems, Theory of Computation, and Design 
and Development Automation. Salary and 
rank are determined by established criteria of 
the University of California. In addition to 
supplying a curriculum vita and a list of 
publications, candidates should either ar¬ 
range for at least three letters of reference to 
be sent or submit the names of at least three 
references. The above materials should be 

Professor Gerhard Gierz 
Chair, Computer Science Recruiting 
Committee 

Department of Mathematics and 
Computer Science 
University of California 
Riverside, CA 92521 
The pool of candidates will consist of all 
those whose completed applications (con¬ 
sisting of a vita, a list of publications, and at 
least three letters of reference) are received 
by February 28, 1989. If the search has not 
been successfully completed by April 5, 
1989, the pool will be enlarged to include all 
those whose completed applications are 
received between March 1, 1989 and April 
5, 1989. 

University of California, Riverside, is an 
Affirmative Action/Equal Opportunity 
Employer. 


INDIANA UNIVERSITY- 
PURDUE UNIVERSITY 
at Indianapolis 

The Department of Computer & Informa¬ 
tion Science invites applications for several 
tenure track positions. A Ph D. in Computer 
Science (or the equivalent) and strong teach¬ 
ing and research credentials are required. 
The Department is expanding and will con¬ 
sider strong candidates in all areas of 
Computer Science. Rank and salary are 
competitive. 

The University is rapidly growing and now 
has over 24,000 students. Indianapolis is a 
large, active metropolis and has available a 
dynamic industrial base conducive to joint 
research and consulting with our faculty. The 
six-hospital Medical Center at IUPUI is yet 
another source of cross-disciplinary research 
for the Department. Outstanding computing 
facilities include a network of VAX, IBM, 
CDC, and Prime machines. Please send 
resumes and references to Dr. Michael A. 
Penna, Chairman Search and Screen Com¬ 
mittee, Department of Computer & Infor¬ 
mation Science, Box 647, IUPUI, Indiana¬ 
polis, IN 46223. IUPUI is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 
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THE OHIO STATE UNIVERSITY 
Department of Computer 
and Information Science 

Applications are invited for faculty posi¬ 
tions at all levels. Of special interest are 
established senior researchers in the areas of 
computer architecture, computer graphics, 
and software systems. Candidates in com¬ 
putational theories of vision and speech, 
theoretical studies on architectures for in¬ 
telligence and conceptual information pro¬ 
cessing are invited to apply for the newly 
established cognitive science program. To 
apply, please send application and resume 
to Prof. Ming T. (Mike) Liu, Chairman of 
Faculty Search Committee, Department of 
Computer and Information Science, The 
Ohio State University, 2036 Neil Avenue, 
Columbus, Ohio 43210-1277. In order to 
expedite consideration of your application, 
please ask three references to send their con¬ 
fidential reference letters directly to Prof. Liu. 
The Ohio State University is an equal oppor¬ 
tunity/affirmative action employer. 


SOUTHEAST MISSOURI STATE 
UNIVERSITY 

The Department of Computer Science in¬ 
vites applications for a tenure track position 
at the associate or full professor level. Duties 
include teaching 6-9 hours of undergraduate 
computer science courses and participation 
in ACM accreditation effort, curriculum 
development, and research coordination. 
Ph.D. in Computer Science, Information 
Systems or closely related area. Please send 
resume with names of three references and 
transcripts of all college credit to: Dr. Bill 
Weber, Chairperson, Department of Com¬ 
puter Science, Southeast Missouri State 
University, Cape Girardeau, MO 63701. 
Application deadline: February 1, 1989 or 
until filled. 

Southeast Missouri State University is an 
equal opportunity/M-F/affirmative action 
Employer. 


FLORIDA INTERNATIONAL 
UNIVERSITY 

The State University of Florida 
at Miami 
Director— 

School of Computer Science 

Florida International University invites ap¬ 
plications and nominations for the position of 
Director of the School of Computer Science. 
We are seeking an individual with excellent 
leadership skills and a distinguished record of 
research together with teaching and admini¬ 
strative experience suitable for appointment 
to the rank of Professor. An earned Doctor¬ 
ate in Computer Science or related field is re¬ 
quired. Salary will be commensurate with 
qualifications. 

The Computer Science program was initi¬ 
ated in 1972 and elevated to the status of a 
School within the College of Arts & Sciences 
in the Fall of 1987. Currently there are 20 
full-time faculty members performing re¬ 
search in many areas of contemporary Com¬ 
puter Science including parallel processing, 


database management, software engineer¬ 
ing, discrete event simulation, computer ar¬ 
chitecture, analysis of algorithms, logic of 
computer programs, computer graphics, AI 
and expert systems. The student population 
of the School includes approximately 600 
undergraduates, 30 master’s students and 
10 doctoral students. 

The School of Computer Science is ex¬ 
pected to play a leading role in the Universi¬ 
ty’s drive to move into the first rank of 
research institutions while maintaining the 
quality of its excellent undergraduate pro¬ 
gram. It enjoys strong support from the Uni¬ 
versity administration and will move into a 
new building in 1989. 

University computing is supported by a 
VAX 8800 system. The resources of the 
School include a Sun network for faculty and 
graduate students, many Transputers and 
Transputer development systems, Symbo¬ 
lics 3610, a Silicon Graphics IRIS 2400 
Graphics system and numerous personal 
computers, all connected via ethernet. A 
$500,000 grant from the State has been in¬ 
strumental in formulation of plans to modify 
the computer laboratory in the School. Sub¬ 
stantial support for additional equipment has 
been committed by the University. 

FIU is the largest public university in South 
Florida. It has more than 17,500 students 
and 600 full-time faculty members. It offers 
167 academic programs and courses at the 
Bachelor’s, Master’s and Doctoral degree 

Nominations and applications (postmarked 
no later than February 16, 1989) including 
the names of 5 referees and should be sent 
to: 

Dr. David Barton 
School of Computer Science 
Florida International University 
University Park 
Miami, Florida 33199 
(305) 554-2032 
BITNET: BARTON@SERVAX 
FIU is an Equal Opportunity/Equal Ac¬ 
cess/Affirmative Action Employer Institution. 


SAINT MARY’S UNIVERSITY 
Computing Science 

Saint Mary’s University, Department of 
Mathematics and Computing Science invites 
applications for a tenure-track position at the 
rank of Assistant Professor effective Septem¬ 
ber 1, 1989. Applicants should have a doc¬ 
toral degree in Computing Science; how¬ 
ever, candidates with doctoral degrees in 
other areas with a strong background in 
Computing Science may be considered. 
Duties will include teaching and research, 
and candidates with a demonstrated ability 
to teach undergraduate Computing Science 
will be given preference. In accordance with 
Canadian immigration requirements, this 
advertisement is directed in the first instance 
to Canadian citizens and permanent resi¬ 
dents; however, all qualified candidates are 
strongly encouraged to apply. Applications, 
including the names of three references, 
should be sent to: Dr. M.T. Kiang, Chairper¬ 
son, Department of Mathematics and Com¬ 
puting Science, Saint Mary’s University, 
Halifax, Nova Scotia, Canada B3H 3C3. 


ROSE-HULMAN INSTITUTE 
OF TECHNOLOGY 
Faculty Position 

Applications are invited for a tenure track 
position in the Department of Computer 
Science beginning Fall 1989. Applicants 
should normally have a doctorate in Com¬ 
puter Science or a closely related discipline. 
Rank and salary are competitive. 

Rose-Hulman is a highly selective, primar¬ 
ily undergraduate, college of science and 
engineering. The 1300 students have an 
average SAT total score greater than 1200. 
The faculty are dedicated to quality teaching 
and continuing professional development. 
Additional information is available by e-mail 
from YoungF@VMS.Rose-Hulman.edu or 
by phone at (800) 248-7448 (Indiana (800) 
552-0725). 

Screening of candidates will begin Feb. 
15, 1989 and continue until the position is 
filled. Send application and supporting 
documents to Prof. Frank H. Young, Rose- 
Hulman Institute of Technology, 5500 
Wabash Avenue, Terre Haute, Indiana 
47803. Rose-Hulman is an equal opportuni¬ 
ty employer. 


UNIVERSITY OF CALIFORNIA 
BERKELEY 

THE UNIVERSITY OF CALIFORNIA 
AT BERKELEY invites applications for 
tenure-track positions in COMPUTER 
SCIENCE beginning in 1989-90, pending 
budgetary approval. Applications for ap¬ 
pointments at the ASSISTANT PROFES¬ 
SOR level will be given highest preference, 
but other levels will be considered. 

The Computer Science Division of the 
Department of Electrical Engineering and 
Computer Sciences is strong and growing. 
We are interested in outstanding Computer 
Science candidates in all areas. 

Research facilities include several main¬ 
frame computers (VAX 8600 and similar), 
numerous LISP machine (Symbolics, TI, 
Xerox) workstations, 80 general-purpose 
networked workstations (SUN and similar), 
and access to an on-site IBM 3090 and Cray- 
XMP. Instructional hardware includes num¬ 
erous SUN workstations, VAX systems, 
Macintoshes, PC’s and mainframes. 

A doctoral degree (or one nearing com¬ 
pletion) in Computer Science or a closely 
related field is required. Applicants should be 
able to teach core undergraduate courses 
and graduate courses. The successful can¬ 
didate must have demonstrated outstanding 
research accomplishments. Send resume, a 
select subset of your best papers, and the 
names of three references by January 30, 
1989, to the address below. 

Professor Richard Fateman 

Associate Chairman for Computer 
Science 

Department of Electrical Engineering 
and Computer Sciences 

University of California 

Berkeley, CA 94720. 

The University of California is an Equal 
Opportunity, Affirmative Action Employer. 
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SYRACUSE UNIVERSITY 
The School of Computer and 
Information Science 

The School of Computer and Information 
Science at Syracuse University expects mul¬ 
tiple openings in all areas of computer 
science at all professional levels. As part of 
our multi-year recruiting plan, we shall em¬ 
phasize this year the core areas of Computer 
Science (Languages, Operating Systems, 
Software Design) and in particular, the sub- 
areas that relate to massively parallel sys¬ 
tems. We shall, however, consider outstand¬ 
ing candidates in any area. 

The School of Computer and Information 
Science operates as part of Syracuse Univer¬ 
sity, a moderate-size private university com¬ 
mitted to excellence in both teaching and 
research. We offer modern facilities, com¬ 
petitive compensation, and a congenial at¬ 
mosphere in a scenic, central, and highly 
affordable part of the country. 

Candidates should submit a statement of 
interest along with three to six names of 
reference and a resume to: 

Faculty Search Committee 

School of Computer and Information 

Syracuse University 

313 Link Hall 

Syracuse, New York 13244-1240 

Application deadline is April 1, 1989. 

Syracuse University is an Affirmative Ac¬ 
tion/Equal Opportunity Employer. 


PURDUE UNIVERSITY 
Computer Engineering 
Faculty Positions 

The School of Electrical Engineering at 
Purdue University seeks outstanding candi¬ 
dates in all areas of Computer Engineering 
for research and teaching. Openings are for 
tenure-track faculty at all levels. Active 
research areas include artificial intelligence 
and expert systems: computer communica¬ 
tion networks; computer vision; design auto¬ 
mation tools; digital signal processor system 
design; distributed algorithms and data¬ 
bases: fault-tolerant and testable computing; 
microprocessor design: neural networks; 
parallel processing (architecture, algorithms, 
operating systems, compiling, languages, in¬ 
terconnection networks, and performance); 
robot vision, sensors and control; software 
engineering: speech processing; and VLSI 
architecture. 

The School has 65 full-time faculty (26 in 
Computer Engineering), and over $8.5M in 
funded research projects. In addition to the 
PhD. MSEE, and BSEE degrees, the School 
offers a BSCEE (Bachelor of Science in 
Computer and Electrical Engineering) which 
is accredited in both Computer Engineering 
and Electrical Engineering. Computing facili¬ 
ties available to the faculty include the Engi¬ 
neering Computer Network (including 17 
VAX 11/780's running UNIX BSD 4.3. 1 
Gould PN 9080. 4 Gould NP l's, a CCI PN 
6/32, and 225 Sun workstations), the Com¬ 
puting Center's Cyber-205 and ETA-10 
supercomputers, a Symbolics LISP ma¬ 
chine. and IBM 3090/180E, extensive 
graphics facilities, and numerous PC's. 


Parallel computing facilities include a 
128-node Ncube hypercube, a 48 x48 pro¬ 
cessor NCR-GAPP processor array, a 10 
processor Transputer array, the 30-proces¬ 
sor PASM Parallel Processor prototype that 
was developed and built at Purdue, and the 
Computing Center’s Sequent Balance 
21000. Custom VLSI chip facilities include 
an IBM Master Image System. Equipment in 
the Robot Vision Lab and Computer Vision 
and Image Processing Lab includes a Puma 
762 robot, a Cincinnati Milacron T3-726 
robot, a K2A Cybermation mobile robot, 
and Gould/DeAnza, Comtal, Grinnell, and 
Imaging Technologies image processing 
systems. Support facilities provided by the 
School include a technical typing pool and a 
graphics illustrator. 

Applicants must possess a doctorate 
degree. Send a resume, including a state¬ 
ment of teaching and research interests and 
a list of three (3) references, to; Head, 
School of Electrical Engineering, Purdue 
University, West Lafayette, IN 47907. Pur¬ 
due University is an Equal Opportunity/Af¬ 
firmative Action employer. 


UNIVERSITY OF VICTORIA 

Department of Computer Science 

Applications are invited for regular full¬ 
time faculty positions to commence July 1, 
1989. These positions are subject to the 
availability of funds. Applications in all areas 
of Computer Science will be considered; ap¬ 
plicants with research interests in theoretical 
Computer Science or in software systems 
are of particular interest. Applicants should 
have a Ph.D. in Computer Science or equi¬ 
valent research achievement. 

The Department has eighteen full-time 
faculty. It offers graduate and undergraduate 
degrees in Computer Science and maintains 
active research programs in programming 
languages, compilers, software engineering, 
software development environments, dis¬ 
tributed computing, combinatorial algo¬ 
rithms, theory of computation, functional 
and logic programming, VLSI design and 
test, and numerical methods. The Depart¬ 
ment is an active participant in the Advanced 
Systems Institute of British Columbia. 

The computing facilities available for in¬ 
structional and research support currently in¬ 
clude SUN 3-280 systems, a VAX 11/780, 
over twenty SUN workstations, microcom¬ 
puter laboratories with a variety of small sys¬ 
tems. as well as the University IBM 3090/ 
VPF system. A local area network provides 
convenient access to these facilities while 
BC-Net provides access to the other univer¬ 
sities and research institutions in the province. 

The city of Victoria, situated on the 
southern tip of Vancouver Island, has a 
population of over 200,000. It enjoys one of 
the most delightful environments in North 
America. The climate is temperate and all 
kinds of outdoor activities, from marine to 
mountain, are popular and can be pursued 
year round. Victoria is exceptionally well- 
endowed with cultural activities too. in¬ 
cluding theatre, opera and a symphony. 

Applicants should send a curriculum vitae 
and the names of at least three referees to: 

Dr. D.M. Miller. Chairman 

Department of Computer Science 


University of Victoria 
P.O. Box 1700 
Victoria, B.C., Canada 
V8W 2Y2 

Applications will be accepted until Febru¬ 
ary 15, 1989. Canadian immigration regula¬ 
tions require the University to assess applica¬ 
tions from Canadian citizens and permanent 
residents of Canada before those of others. 
Women are particularly encouraged to apply. 

Further information is available by con¬ 
tacting the Chairman of the Department. 
UUCP: [uw-beaver,ubc-vision]!uvicctr! 
dmill 

BITNET: dmill@uvunix.bitnet 
INTERNET: dmill@uvunix.uvic.ca 
Telephone: (604) 721-7220 
Fax: (604) 721-8653 
Telex: 049-7222 


THE UNIVERSITY OF MICHIGAN- 
DEARBORN 

Tenure track position at Assistant/Associ¬ 
ate Professor level available at the University 
of Michigan-Dearborn starting 9/89. Ap¬ 
pointment in the Department of Mathema¬ 
tics with primary responsibilities in Inter- 
diciplinary Computer Science program 
(Business, Engineering, Mathematics). 
Ph.D. in one of the computer or information 
sciences with graduate level work in one of 
the mathematical sciences or a Ph.D. in one 
of the mathematical sciences with a Masters 
Degree or equivalent in one of the computer 
or information sciences required. Nine hour 
teaching load per semester, released time for 
research available to junior faculty. The 
Dearborn campus is one of three in the Uni¬ 
versity of Michigan system. Send a vita, 
three letters of recommendation, and official 
transcripts to: Chair, Search Committee, 
Dept, of Mathematics, University of Michigan- 
Dearborn, Dearborn, MI 48128-1491. The 
University of Michigan is an equal opportunity 
employer and specifically invites and encour¬ 
ages applications from women and minorities. 


PACIFIC LUTHERAN UNIVERSITY 

Tenured track position as assistant or 
associate professor Computer Science avail¬ 
able September, 1989. Teach graduate and 
undergraduate classes in computer science. 
Ph D. in computer science or equivalent re¬ 
quired. Interest in systems desirable. Strong 
emphasis on quality teaching in small 
classes. Facilities include a VAX 6210/6220 
Cluster. Sun workstations, HP9000, Intel 
Hypercube, and microcomputers. Send 
vita, transcripts and 3 letters of recommen¬ 
dation (including evidence of teaching abili¬ 
ty) to James Brink. Chair. Dept, of Math and 
Computer Science, Pacific Lutheran Univer¬ 
sity, Tacoma. WA 98447. Enquiries (206) 
535-7409. Applications will be accepted un¬ 
til position is filled. Position subject to ad¬ 
ministrative approval. An equal opportunity/ 
affirmative action employer. Women and 
minorities encouraged to apply. 
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THE UNIVERSITY OF MICHIGAN 

Computer Science and Engineering 
Division 

The Department of Electrical Engineering 
and Computer Science at The University of 
Michigan invites applications for tenure-track 
positions in its Computer Science and Engi¬ 
neering Division. Located in a new building 
on the North Campus and with a strong 
commitment from the University, the Divi¬ 
sion is entering an exciting period of further 
expansion. 

The University of Michigan has a long 
history in software development, and is in¬ 
terested in expanding its coverage of the field 
particularly at mid-career or senior levels. 
Possible appointments are available primari¬ 
ly in the areas of operating systems, software 
engineering and networks. In theoretical 
computer science we seek a junior faculty 
member with interests compatible with our 
current efforts in logic or parallel algorithms. 
All candidates who apply should have an in¬ 
terest in teaching and a strong research 
orientation. 

Send your resume and the names of at 
least three references to Professor Keki B. 
Irani, Associate Chairman, Computer Sci¬ 
ence and Engineering Division, Department 
of Electrical Engineering and Computer 
Science, The University of Michigan, Ann 
Arbor, Michigan 48109-2122. The Universi¬ 
ty of Michigan is an Equal Opportunity/Affir¬ 
mative Action Employer. 


WRIGHT STATE UNIVERSITY 

Department of Computer Science 
and Engineering 
Dayton, OH 45435 

Applicants are invited for tenure-track and 
visiting faculty positions at all levels. Suc¬ 
cessful candidates for tenure-track positions 
should have a Ph.D. in computer science, 
computer engineering, or equivalent back¬ 
ground and have demonstrated forward 
looking and creative research. Further 
desired attributes include: capability to direct 
Ph.D. candidates in computer science or 
computer engineering and the ability to ac¬ 
quire funds and/or direct research projects. 
All technical areas will be considered but AI 
related areas including machine learning and 
neural networks are of particular interest. 
Rank and competitive salaries are determined 
by qualifications and experience. 

The university is located in a high technol¬ 
ogy environment among industrial/military 
research and development facilities including 
Wright-Patterson Air Force Base and NCR. 
The graduate program has excellent offices 
and computing facilities in the WSU Re¬ 
search Center located in a fast growing 
associated state-assisted research park 
fostering basic and applied industrial/ 
military/university research. The Center for 
AI Applications and the Edison Materials 
Technology Center (EMTEC) funding 
organizations are located in the same 
building. 

Department strengths include a large 
faculty, extensive laboratory facilities in¬ 
cluding graduate laboratories in AI, optical 
computing, neural networks, and robotics, 


established research programs, industrial/ 
military support, degree programs in both 
computer science and computer engineer¬ 
ing, and large student populations at gradu¬ 
ate as well as undergraduate levels. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress: amcaulay@wright.edu or Alastair D. 
McAulay, NCR Distinguished Professor and 
Chair, Department of Computer Science 
and Engineering, Wright State University, 
Dayton, OH 45435. Reviewing for positions 
will begin immediately and continue monthly 
until positions are filled or until April 1, 1989. 

An equal opportunity/affirmative action 
employer. 


TEMPLE UNIVERSITY 
Faculty Positions 
Department of Computer and 
Information Sciences 

The Department of Computer and Infor¬ 
mation Sciences has tenure-track adjunct 
and visiting faculty positions available in the 
area of Information Systems. 

Applicants should hold the Ph.D. degree 
in Information Systems, Computer Science 
or a closely related field. The ability to con¬ 
tribute to strong instructional and research 
programs, both graduate and undergradu¬ 
ate, will be the primary requisite for appoint¬ 
ment. Salary and rank will be determined by 
the appointee’s experience. Research areas 
of primary interest include: Information 
Systems Development Methodologies, 
Human Factors, Data Base Management 
Systems, Software Engineering, Knowledge 
Based Systems, Model Management/Multi¬ 
ple Criteria Decision Support Systems, Infor¬ 
mation Systems Policy/Information Re¬ 
source Management and Organizational 
Support Systems (MIS, DSS, OIS). An ap¬ 
plicant for a senior position should have a 
strong record of scholarly achievement, 
while an applicant for an assistant professor¬ 
ship should present evidence of research 
potential. 

The Department of Computer and Infor¬ 
mation Sciences offers programs leading to 
the Bachelors, Masters and Ph.D. degrees in 
Business Administration/Information Sci¬ 
ence as well as in Computer Science. Cur¬ 
rently the department has a full-time faculty 
of 27; there are 300 graduate students 
enrolled in the masters and Ph.D. programs, 
and 1200 undergraduate majors. 

A networked departmental computing fa¬ 
cility includes a VAX-11/780, VAX-11/750, 
and 20 microVAX systems configured as 
time-shared systems and workstations. The 
facility also includes an AT&T 3B20, an 
AT&T 3B2, a T1 Explorer, an image pro¬ 
cessing laboratory and other special purpose 
computers. Departmental instructional 
laboratories use VAX (VMS or UNIX) 
systems, as well as microcomputers. Univer¬ 
sity facilities currently in use by the depart¬ 
ment include a CDC Cyber, an IBM 4381, a 
graphics laboratory and several microcom¬ 
puter laboratories. A multi-processor, high 
speed computing facility is also available for 
use. ARPANET, CSNET, and BITNET ac¬ 
cess is available through a variety of depart¬ 
ment and university hosts. 


Temple University is an Equal Oppor¬ 
tunity/Affirmative Action Employer and 
specifically invites and encourages applica¬ 
tions from women and minorities. To apply, 
submit vitae, and bibliography to: 

Elliot Koffman, Chairman of 
Faculty Search Committee 
Department of Computer and 
Information Sciences 
Temple University 
Computer Activities Building, 38-24 
Philadelphia, PA 19122 


UNIVERSITY OF ALASKA 

The Computer Science faculty invite ap¬ 
plications for anticipated tenure-track and 
visiting faculty positions, to be filled 
September, 1989. Rank depends on qualifi¬ 
cations. The University of Alaska Fairbanks 
is the major research institution in the 
University of Alaska system and is the site of 
several world famous research institutes. 
The Department of Mathematical Sciences 
offers B.S. and M.S. degrees in Computer 
Science. The University facilities include a 
research quality library and a statewide com¬ 
puter network of VAX 8800 and 8600 com¬ 
puters. In addition, the Department has a 
VAX. several Masscomp color graphics 
workstations, and smaller computers. Ap¬ 
plicants with research interests in any field 
will be considered. Salary is competitive and 
fringe benefits are excellent. Resume and 
three letters of reference should be directed 
to Dr. Barbara Lando, Department of Mathe¬ 
matical Sciences, University of Alaska, Fair¬ 
banks, AK 99775-1110. Inquiries: (907) 
474-7117 or FFBML@ALASKA.BITNET. 
Deadline for applications: March 1, 1989. 
UAF is an Equal Opportunity/Affirmative 
Action employer and educational institution. 


SCIENTIST 

COMPUTED TOMOGRAPHY 

SCIENTIST COMPUTED TOMO¬ 
GRAPHY for research and manufacturing 
firm in NE Ohio to design, develop, imple¬ 
ment and integrate REAL-TIME control and 
image processing software for diagnostic im¬ 
aging systems, utilizing the “C" computer 
language. Additionally develop complex 
mathematical models and algorithms involved 
in signal and image processing. Educational 
requirement is an MS Degree in one of the 
following majors: Electrical Engineering with 

5 graduate level mathematics courses; Phy¬ 
sics with concentration in Applied Elec¬ 
tronics, Digital Signal Processing, Image 
Processing for Medical Applications and 5 
graduate level mathematics courses; or 
Biomedical Engineering with concentration 
in Digital Signal Processing, Image Process¬ 
ing and 5 graduate level mathematics, 
courses. Must have 1 year experience in the 
job described or 1 year experience in the field 
of REAL-TIME Image Processing, including 

6 months of practical field experience with 
clinical applications. 40 hrs/wk. 8am-5pm, 
$34,000/yr. Qualified applicants reply by 
resume to C. Bussard JO» 1084413 OHIO 
BUREAU OF EMPLOYMENT SERVICES, 
PO Box 1618, Columbus, OH 43216. 
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WESTERN KENTUCKY UNIVERSITY 
Computer Science Faculty Positions 

The Computer Science Department in¬ 
vites applications for tenure-track positions at 
the Assistant Professor level for 1989-90. 
Qualifications include a doctorate in Com¬ 
puter Science or related area. Candidates 
should be qualified in one or more of the 
following: systems programming, compilers, 
programming languages, data base, archi¬ 
tecture, artificial intelligence/expert systems, 
or software engineering. Candidates with 
master’s degree may be considered for In¬ 
structor. The program offers bachelor’s and 
master’s degrees, with over 300 under¬ 
graduate majors and minors and 30 master’s 
candidates. Computer facilities include: IBM 
4381, VAX 11/785, PDP 11/44 (UNIX) TI 
Explorer, 125+ microcomputers, expert 
systems, CASE and CBE tools, CSNET and 
BITNET. WKU is located in Bowling Green, 
KY, 2 hours south of Louisville and 1 hour 
north of Nashville, TN, with a population of 
56,000. Housing costs are less than 90% of 
the national norm. Rank and salary negotia¬ 
ble depending upon qualifications. Review 
of applications will begin January 30, 1989. 
Send letter of application, vita, and names of 
at least three references to: Office of Aca¬ 
demic Affairs, Computer Science Search, 
Western Kentucky University, Bowling 
Green, KY 42101. Women and minorities 
are encouraged to apply. An Affirmative Ac¬ 
tion, Equal Opportunity Employer. 


THE UNIVERSITY OF TENNESSEE 
AT CHATTANOOGA 
(Search Re-opened) 

Tenure track position in Computer Sci¬ 
ence. Applicants should have a Ph.D. in 
Computer Science or a related field. Rank 
and salary are open and competitive. Appli¬ 
cants with experience in Computer Architec¬ 
ture or Operating Systems are especially en¬ 
couraged but those with interests in other 
areas are also welcomed. 

UTC offers BS and MS degrees in Com¬ 
puter Science. It is the site of Tennessee’s 
Center of Excellence for Computer Applica¬ 
tions. Available resources include IBM 3090 
and 4381 systems, several HP3000’s and 
numerous microcomputers. 

Chattanooga, located in one of the coun¬ 
try’s most scenic areas, offers excellent 
recreational opportunities and has a low cost 
of living. There is no state income tax. 

Send applications to: 

Dr. Jack Thompson, Head 
Computer Science Department 
School of Engineering 

University of Tennessee at Chattanooga 
615 McCallie Avenue 
Chattanooga, TN 37403 
Phone (615) 755-4349 

Applications will be reviewed beginning 
March 1, 1989. An appointment will be 
made as soon as the successful candidate is 
selected. 

The University of Tennessee is an Equal 
Opportunity/Affirmative Action Employer. 


McMASTER UNIVERSITY 
Communications Research Laboratory 
(Telecommunications Research 
Institute of Ontario) 
and Department of 
Computer Science and Systems 
Faculty Position 

The Communications Research Labora¬ 
tory (CRL), through its affiliation with the 
Telecommunications Research Institute of 
Ontario, and in partnership with the Depart¬ 
ment of Computer Science and Systems is 
well along in establishing a unique “com¬ 
puting environment for advanced research 
in signal processing.” 

In keeping with this objective the Depart¬ 
ment invites applications for a faculty posi¬ 
tion from candidates who have a Ph.D., 
demonstrated teaching ability, and a proven 
research record in one or more of the general 
areas of parallel system architecture, pattern 
recognition, and computer vision. 

The successful candidate will also be a 
member of the CRL with the privilege of ac¬ 
cess to advanced research facilities and the 
opportunity to conduct world-class research 
under the umbrella of TRIO a “Centre of Ex¬ 
cellence." Departmental responsibilities in¬ 
clude teaching at the undergraduate and 
graduate levels and the supervision of gradu¬ 
ate students. Salary is competitive for a 
tenure-track position and commensurate 
with qualifications and experience. 

Please provide a curriculum vitae and ar¬ 
range for three letters of reference, to be sent 
to (or request additional information from): 

Dr. S. Haykin, Director 

Communications Research Laboratory 
OR 

Dr. G.L. Keech, Chairman 
Computer Science and Systems 
McMaster University 
Hamilton, Ontario 
L8S 4K1 

Deadline for Applications: March 
31, 1989. 


RENSSELAER POLYTECHNIC 
INSTITUTE 

The Computer Science Department in¬ 
vites applications for tenure-track faculty 
positions at all academic ranks. Research, 
visiting and postdoctoral appointments may 
also be available. Applicants should have a 
Ph.D. in Computer Science (or a related 
area) and a commitment to excellence in 
teaching and research. Preferred research 
interests are parallel computation, database 
systems, computer graphics, computer vi¬ 
sion, image processing, VLSI systems and 
symbolic computation; however, all areas 
will be considered. The department offers 
B.S., M S., and Ph.D. degrees in Computer 
Science and has excellent computing facili¬ 
ties. Send resumes and at least three refer¬ 
ences to Joseph E. Flaherty, Chairman, De¬ 
partment of Computer Science, Rensselaer 
Polytechnic Institute, Troy, New York 
12180-3590. Rensselaer is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


BOSTON UNIVERSITY 
Software Engineering Faculty Position 

The Department of Electrical, Computer 
and Systems Engineering at Boston Univer¬ 
sity seeks applications for a faculty position at 
the Associate/Full Professor level in the area 
of Software Engineering. The position is in 
the area of embedded computer systems for 
real time applications. 

With strong support from industry in the 
Rts. 128 and 495 area surrounding Boston, 
the Department is committed to building a 
software engineering program of national 
prominence. The Ph.D. degree is offered 
through the Boston University Graduate 
School, and the faculty of the College has 
approved a forward looking Master’s Degree 
program which will focus on the design of 
software for real-time embedded systems 
and distributed systems. Teaching and 
research laboratories which emphasize these 
areas are being installed in the new Engi¬ 
neering Research Building occupied by the 
Department in 1987. 

Applicants should send their curriculum 
vitae to Professor Thomas G. Kincaid, 
Chairman, Department of Electrical, Com¬ 
puter and Systems Engineering, College of 
Engineering, Boston University, Boston, 
MA 02215. Potential applicants who wish to 
know more about the position before apply¬ 
ing should call Professor Kincaid at (617) 
353-2806. Boston University is an Equal 
Opportunity/Affirmative Action Employer. 


UNIVERSITY OF BRITISH COLUMBIA 

The University of British Columbia invites 
applications at the assistant/junior associate 
professor level in computer engineering. 
Areas of interest include software engineering, 
advanced computer architecture, fault toler¬ 
ant computing, real-time systems, artificial in¬ 
telligence and expert systems, computer 
graphics or image processing, and com¬ 
puter communications. A Ph.D. is re¬ 
quired. Industrial experience would be an 
asset. Successful applicants will be ex¬ 
pected to vigorously pursue research and to 
teach at the undergraduate and graduate 
levels. Research collaboration with the 
Department of Computer Science is en¬ 
couraged and facilitated through the Centre 
for Integrated Computer Systems Research. 
Salary is commensurate with qualifications 
and experience. Applications will be con¬ 
sidered until positions are filled, although a 
practical cut-off date for September 1989 is 
April 15, 1989. 

To apply, send curriculum vitae, reprints 
of published papers, and names of at least 
three references, and state whether or not 
the applicant is a Canadian citizen or perma¬ 
nent resident of Canada to: 

Dr. R.W. Donaldson, Head 
Department of Electrical Engineering 
2356 Main Mall 

The University of British Columbia 
Vancouver, B.C., Canada V6T 1W5 
The University of British Columbia offers 
equal opportunity for employment to quali¬ 
fied female and male applicants. In accor¬ 
dance with the Canadian immigration re¬ 
quirements, priority will be given to Canadian 
citizens and permanent residents of Canada. 
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CASE INSTITUTE OF TECHNOLOGY 
Nord Professorship in 

Computer Engineering and Science 

The Department of Computer Engineering 
and Science at Case Institute of Technology 
is seeking a nationally recognized scholar 
and researcher to fill the NORD Professor¬ 
ship. This position was recently established 
by the donation of one and a half million 
dollars, which will provide outstanding pro¬ 
fessional opportunities and a highly com¬ 
petitive salary, together with additional funds 
for travel, graduate student support and 
equipment. The qualifications include a 
Ph.D. in computer science, computer engi¬ 
neering or closely allied fields, and an ability 
to establish and develop external support for 
a nationally recognized research program in 
computer science/computer engineering. 
Another requirement of this position is ex¬ 
cellent teaching at both the undergraduate 
and graduate levels. We invite applications 
from senior faculty at both the associate pro¬ 
fessor and full professor levels. 

CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 15 faculty positions, and 
a graduate student body of 140 students, 50 
of which are in the Ph.D. program. Depart¬ 
mental facilities are based upon an ethemet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating 
system and about 30 SUN workstations, 
color graphics display terminals, together 
with several printers. In addition, faculty and 
students participating in the Center for Auto¬ 
mation and Intelligent Systems Research 
have access to the Center’s computing 
facilities. 

Applicants should submit their curriculum 
vitae and names of at least five references to: 
Lee J. White, Chairman, Department of 
Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106; INTERNET: leew@ 
alpha.ces.cwru.edu; applicants may wish to 
provide at most three reprints of their most 
important publications. 

An equal employment and affirmative ac¬ 
tion employer. 


THE UNIVERSITY OF ALABAMA 
IN HUNTSVILLE 
Search Continued for 
Eminent Scholar Chair 
in Computer Engineering 

The Electrical and Computer Engineering 
Department of The University of Alabama in 
Huntsville (UAH) announces the establish¬ 
ment of an Eminent Scholar Chair in Com¬ 
puter Engineering and invites applications 
and nominations for the position. 


The professorial chair is endowed through 
contributions from anonymous donors and 
the State of Alabama. The successful can¬ 
didate will be granted tenure on the initial ap¬ 
pointment and will be given a reduced teach¬ 
ing load, research and secretarial assistance, 
and a salary commensurate with qualifica¬ 
tions. The position is available beginning 
September 1989. 

Qualifications for the candidate include (a) 
an earned doctorate in computer engineer¬ 
ing, electrical engineering or related dis¬ 
cipline, (b) strong leadership capabilities in 
both sponsored research and graduate teach¬ 
ing activities, (c) capability to interact produc¬ 
tively with the industrial community and 
governmental agencies in the area, (d) 
strong evidence of scholarly activity, (e) U.S. 
Citizenship, and (f) a national and interna¬ 
tional reputation in the fields of software and 
hardware computer engineering. 

The Chair is expected to work closely with 
the faculty of the Department and the Col¬ 
leges of Engineering and Science, and to in¬ 
teract with University research units such as 
the Center for Robotics, the Center for Ap¬ 
plied Optics, the Cognitive Systems Labora¬ 
tory, and the Artificial Intelligence Learning 

The College of Engineering, the Universi¬ 
ty, local industry and the Federal agencies of 
the area strongly support the Chair and pro¬ 
vide an excellent environment and support 
facilities for research at the highest level. 
UAH has access to excellent computer facil¬ 
ities, including a State Supercomputer 
(CRAY X-MP/24) which is located adjacent 
to the UAH campus. Huntsville is a high- 
technology city with congenial living and 
unique cultural environment. 

Nominations and vitae with the names, 
addresses and telephone numbers of refer¬ 
ences, should be sent to: Dr. Lynn Russell, 
Dean, College of Engineering, University of 
Alabama in Huntsville, Huntsville, Alabama 
35899. 

The position will remain open until an ac¬ 
ceptable candidate is found; however, the 
Search Committee will begin reviewing ap¬ 
plications not later than February 20, 1989. 

The University of Alabama in Huntsville is 
an Equal Opportunity/Affirmative Action 
Employer. 


UNIVERSITY OF MARYLAND 
UNIVERSITY COLLEGE 
Faculty for Europe and Asia 

Planning a sabbatical or leave of absence? 
The University of Maryland University Col¬ 
lege seeks excellent lecturers for under¬ 
graduate computer science, computer appli¬ 
cations, and information systems manage¬ 
ment courses on U.S. military bases in 
Europe and in Asia and the Pacific. Renew¬ 
able annual appointments begin August 
1989. Minimum requirements include a 
master’s degree in computer science or a 
related field, recent college teaching ex¬ 
perience, and U.S. citizenship. Benefits in¬ 
clude transportation and military base 
privileges. Frequent travel and the cost of 
schooling make these positions difficult for 
those with children. Send resume to Dr. 
Ralph E. Millis, Overseas Programs, The 
University of Maryland University College, 
College Park, MD 20742-1642. AA/EEO. 


UNIVERSITY OF NORTH TEXAS 
Department Chair 
Computer Sciences 

Applications and nominations are invited 
for the position of Chair of the Department of 
Computer Sciences. The department offers 
B. S., M. S. and Ph. D. programs with approxi¬ 
mately 500 undergraduate and 150 gradu¬ 
ate majors. Current strengths among the 19 
faculty include parallel and distributed com¬ 
puting, logic programming, artificial intelli¬ 
gence, expert systems, databases, languages, 
numerical computation, and operating sys¬ 
tems. Substantial faculty growth is projected 
over the next five years. Excellent facilities 
support both research and instruction. 

The University of North Texas is a com¬ 
prehensive, graduate research university of 
approximately 24,000 students, offering an 
array of undergraduate, master’s and doc¬ 
toral programs. The university is located in 
Denton, at the center of one of the fastest 
growing counties in the nation, less than 
forty miles from both Dallas and Fort Worth. 
The Dallas-Fort Worth-Denton Metroplex 
abounds in cultural activities and high tech¬ 
nology industries. 

Substantial research accomplishments are 
essential; grant activity and administrative 
experience are desirable. Apply to Chair 
Search Committee, Department of Com¬ 
puter Sciences, Box 13886, University of 
North Texas, Denton, TX 76203. Applica¬ 
tions should include a curriculum vitae and 
the names, addresses and telephone num¬ 
bers of at least three references. Applications 
will be received until the position is filled. 

UNT is an equal opportunity/affirmative 
action employer. 


GALLAUDET UNIVERSITY 
Department of Mathematics 
and Computer Science 

Applications are invited for a tenure-track 
position in Computer Science at the Instruc¬ 
tor or Assistant Professor level, available 
August 1989. Applicants are expected to 
have a commitment to excellence in teach¬ 
ing and must have at least a Master’s in Com¬ 
puter Science with experience or course 
work in, but not limited to, such subjects as: 
Software Engineering, Artificial Intelligence, 
Computer Graphics, Discrete Mathematics, 
Database and Knowledge Systems or Com¬ 
puter Networks. 

Gallaudet University, a small institution of¬ 
fering undergraduate programs for the deaf 
students and graduate programs for both 
hearing and deaf, is located in Washington, 
D.C. Hearing-impaired individuals are en¬ 
couraged to apply for the position. Ap¬ 
pointees without sign language skills will be 
required to attend an 8-week paid sign 
language training program in June, 1989. 

Closing date for application is March 1, 
1989, or until the position is filled. Send vita, 
transcripts, and three letters of reference to: 
Prof. Herbert G. Mapes, Chair, Department 
of Mathematics and Computer Science, Gal¬ 
laudet University, Washington, D.C. 20002. 

Gallaudet University is an EOE/AA 
employer. 
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TEXAS A&M UNIVERSITY 

Endowed Chair in Microelectronics/ 
Computer Architecture 

Texas A&M University invites nomination 
of qualified individuals for an endowed chair 
in microelectronics, with specialization in the 
area of Computer Architecture. Candidates 
should have outstanding professional and 
persona] qualifications, including national 
and international recognition for contribu 
tions in computer architecture. Nominations 
of qualified individuals from both industrial 
and academic backgrounds are solicited. 
The successful candidate will be expected to 
provide leadership in both research and 
teaching in the computer architecture area. 
The academic rank will, of course, be Pro¬ 
fessor with tenure. 

Texas A&M is making a major commit¬ 
ment to establishing and maintaining an out¬ 
standing program in Computer Science and 
Engineering. A substantial external contribu¬ 
tion has enabled the creation of a heavily en¬ 
dowed chair in the microelectronics and 
computer architecture area as part of this ef¬ 
fort. A new building is under construction for 
the Department. With the building the De¬ 
partment will receive a major allocation of 
funds for new equipment. In addition, the 
College is preparing to make substantial irr- 
vestments in facilities to support leading edge 
research in areas involving advanced com¬ 
puter architectures. There is also strong in¬ 
dustry support for Department advances and 
ample opportunity for joint industry/univer¬ 
sity endeavors. The successful candidate can 
play a major role in the decisions to be made 
in these areas, and will have the opportunity 
to shape the direction of computer architec¬ 
ture research in the Department. Substantial 
resources will be made available for carrying 
out this work. 

Related microelectronics research activi¬ 
ties in the area of integrated circuits and 
systems include analog and digital integrated 
circuit design, VLSI system design, design 
automation, microprocessor architectures, 
and design for yield optimization. CAD 
facilities and software for IC design, layout 
and verification are available. A test and 
evaluation laboratory includes equipment for 
wafer handling, IC packaging, process 
characterization, and electronic test and 
evaluation. 

Please send nominations to Prof. Richard 
A. Volz, Head, Department of Computer 
Science, Texas A&M University, 241 Zachry 
Engineering Center, College Station, Texas 
77843. Initial screening will include applica¬ 
tions received prior to April 1, 1989. Minori¬ 
ties and woman are particularly encouraged 
to apply. 


UNIVERSITY OF DELAWARE 
Department of Computer and 
Information Sciences 

Are you interested in joining the computer 
science faculty of a growing, dynamic de¬ 
partment in an attractive university town 
within easy traveling distance to New York, 
Philadelphia, Baltimore, and Washington? 
The University of Delaware, centrally 
located on the East Coast, is recruiting for 


possible openings for tenure-track and visit¬ 
ing faculty positions in the Department of 
Computer and Information Sciences begin¬ 
ning September 1, 1989. The department 
has active groups working in artificial intelli¬ 
gence, networks, and symbolic mathemati¬ 
cal computation. Special interest exists for 
candidates with research expertise in ar¬ 
chitecture, operating systems, parallel pro¬ 
cessing, databases, theory of computation, 
programming languages, or software engi¬ 
neering. Strong applicants in all areas of 
computer science are encouraged to apply. 

A Ph.D. degree or its equivalent, and ex¬ 
cellence in research and teaching are re¬ 
quired. Salary and rank will be commensur¬ 
ate with the candidate’s qualifications and 
experience. 

The Department research facilities include 
various workstations (primarily Symbolics 
Lisp machines and SUN’s) and facilities in a 
joint research lab shared with the Depart¬ 
ment of Electrical Engineering. The latter in¬ 
cludes a Sequent Symmetry, VAX-8500, 
three VAX 780’s and various other smaller 
machines. We are well connected to the 
major networks. 

The Computer and Information Sciences 
Department offers bachelor, master, and 
doctoral degrees. Resources devoted to 
academic use in the University Computing 
Center include an IBM 3090-300 with a vec¬ 
tor facility, a CDC Cyber 180, Unix 
machines (Vax 8650, Pyramid 98xe, Sun 4 
with 128MB memory, 12 Sun 3/60’s), and 
more than 75 microcomputers (IBM PC- 
XT's, AT’s and Macintosh’s). 

Candidates should send a curriculum 
vitae and the names of three references to 
Dr. David Saunders, Acting Chair, Depart¬ 
ment of Computer and Information 
Sciences, University of Delaware, Newark, 
DE 19716. Positions are open until filled. 

The University of Delaware is an equal op¬ 
portunity, affirmative action employer. Ap¬ 
plications from members of minority groups 
and woman are encouraged. 


WEST VIRGINIA UNIVERSITY 
Assistant Vice President 
Computing and Information Resources 

West Virginia University invites applica¬ 
tions and nominations for the position of 
Assistant Vice President for Computing and 
Information Resources. This land grant Uni¬ 
versity has more than 18,000 students en¬ 
rolled in 175 degree programs and is the 
state’s major research university. The annual 
budget exceeds 230 million dollars. 

RESPONSIBILITIES: The Assistant Vice 
President reports to the Provost and is 
responsible for administering academic ser¬ 
vice personnel and budgets, coordinating 
support services; recommending the alloca¬ 
tion of resources; developing plans and 
recommending policy for academic and ad¬ 
ministrative computing, communications, 
and information resource management; and 
acting as chief liaison with statewide and 
national computing resource centers. 

QUALIFICATIONS: Candidates for this 
position will be expected to possess an earned 
doctorate or masters degree; have held 
senior level administrative positions; demon¬ 


strate a proven record of accomplishment in 
planning, implementation and management 
of computing and telecommunication sys¬ 
tems in a multifaceted environment; exhibit 
an understanding of academic, ad¬ 
ministrative and research computing needs; 
possess knowledge of computing, com¬ 
munication and information systems and ex¬ 
hibit the ability to communicate with and 
provide leadership for a broad range of con¬ 
stituencies. 

SALARY: Competitive. 

STARTING DATE: July 1, 1989 or as 
soon as possible after the conclusion of the 
selection process. 

DEADLINE FOR APPLICATIONS: Ac¬ 
cepted until the position is filled with screen¬ 
ing beginning January 15, 1989. 

APPLICATION PROCEDURE: West Vir¬ 
ginia University is committed to affirmative 
action and invites nominations for and 
applications from women and minority 
candidates. Submit letter of application, 
curriculum vita and names, addresses and 
telephone numbers of three professional 
references to: 

Dr. William E. Vehse, Chairperson 
Search Committee for Assistant VP, 
Computing & Information Resources 
308 Stewart Hall 
West Virginia University 
Morgantown, WV 26506 
An Affirmative Action/Equal Opportunity 
Employer. 


UNIVERSITY OF LOUISVILLE 
Engineering Mathematics and 
Computer Science Positions 

The School is seeking qualified individuals 
for engineering mathematics and computer 
science positions, assistant/associate pro¬ 
fessor, 12 months, tenure track starting the 
1988-89 academic year. Requirements in¬ 
clude Ph.D. with specialization in Computer 
Science, Computer Engineering, or in Engi¬ 
neering. Candidates should have teaching 
and research interests in Database Design, 
Compiler Design, or Artificial Intelligence. 
Candidates having interests in closely related 
areas will be considered. 

Strong preference will be given to can¬ 
didates with an engineering background. 
Responsibilities include research and the 
teaching of graduate and undergraduate 
courses. Excellent computing facilities are 
available including DEC 8650 VAX with a 
VAX Cluster; IBM 3081; and Vision Sys¬ 
tems, a VAX based sound system, graphics 
equipment, AI Symbolics and DEC worksta¬ 
tions, and micro systems in departmental 
laboratories in a local area network. The 
department offers Masters of Engineering in 
Computer Science and Ph.D. degrees in 
Computer Science and Engineering. Ex¬ 
pected start date is August 15, 1989, but ap¬ 
plications will be accepted until position is 
filled. 

Send application and resume to; 

Dr. Khaled A. Kamel, Chairman 
Department of Engineering Mathematics 
and Computer Science 
Speed Scientific School of Engineering 
University of Louisville 
Louisville, Kentucky, 40292 
AA/EEO 
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IEEE COMPUTER SOCIETY 


IEEE COMPUTER SOCIETY <0> 

Membership / Subscription Application 


BENEFITS 


Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called “The Open Channel.” 
(monthly). 

Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50°/o on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 



To join: see item 1, 2, or 3. 
Schedule of Fees To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, 
and expire on, December 31. Choose full or half-year rate schedules 
depending on date of receipt by the Computer Society Half Year Full Year 
as indicated below. Mar 1-Aug 31 Sept 1-Feb 28 

I I don’t belong to the IEEE and I want □ $19.50 □ $39.00 

to join just the Computer Society 

2 1 don’t belong to the IEEE and I want 

to join both the Computer Society and the IEEE* 

(Total amount to be paid includes annual dues, and regional assessment, if any.) 

I reside in Region 1-6 (United States). □ $44.00 □$88.00 

I reside in Region 7 (Canada). □ $41.00 □ $82.00 

I resideinRegion8(Europe, Africa, orthe Middle East) □ $41.50 □$83.00 

I reside in Region 9 (Latin America). □ $36.00 □ $72.00 

I reside in Region 10 (Asia and Pacific). □ $37.00 □ $74.00 

*ACM members who join both IEEE and the Computer Society may deduct $5 off the 
full-year rate; $2.50 off the half-year rate. 

3 1 already belong to the IEEE and I want □ $ 7.50 □ $15.00 

to join the Computer Society. 

IEEE Member Number_ 


^ OPTIONAL PERIODICALS for new or current members 

IEEE Computer Graphics and Applications (3061) 6 □$ 9.50 □ $19.00 


IEEE Design and Test (3111) .6 □ $10.00 □ $20.00 

IEEE Expert (3151) .4 □ $ 6.00 □ $12.00 

IEEE Micro (3071) .6 □ .$ 9.00 □ $18.00 

IEEE Software (3121) .6 □$9.00 □$18.00 

Transactions on Computers (1161) .12 □ $10.00 □ $20.00 

S e* Transactions on Knowledge and 

sp'^ 9 Data Engineering (1471) .4 □$5.00 □ $10.00 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Understanding Computers and Cognition: 
A New Foundation for Design 


Terry Winograd and Fernando Flores 

(Addison-Wesley, Reading, Mass., 

1987,207 pp„ $12.95) 

It is natural for designers of computer 
systems to view their craft as strictly a 
technical one. The purpose of this book is 
to sensitize designers to the broader 
issues of computer system design by 
showing how philosophical considera¬ 
tions about the nature of language and 
human action have practical relevance. 
The authors hope that designers will 
become open to alternatives and new 
design possibilities through awareness of 
the traditions of thought and the assump¬ 
tions used in a design. 

When this book was published, the 
journal Artificial Intelligence thought that 
its criticisms of AI were important 
enough to assign four reviewers to it and 
to devote 50 pages to these reviews and a 
response by the authors (February 1987). 
Those reviews were concerned with AI; 
the present review will focus on the last 
part of the book, which is devoted to the 
design of computer systems. 

A description of the first part of the 
book is necessary to understand the 
motivation of the third part. Part I 
describes the rationalistic position 
(concerned with logical deduction and 
conscious reflection) and then presents 
the contrary view that individual 
interpretations and intuitive understand¬ 
ing play a central role in much of human 
interaction. 

The authors reject the idea that 
cognition is the manipulation of knowl¬ 
edge of an objective world. A main theme 
is that language is a form of human social 
action that does not convey information, 
but rather evokes an understanding — an 
interaction between what was said and 
the preunderstanding already present in 
the listener. Thus, an utterance produces 
a different understanding for each listener 
since each person has a background of 
preunderstanding generated by a 
particular history. The authors’ exposi¬ 
tion of the subtleties of language and 


action is intelligible, even though many 
of the ideas are taken from erudite areas 
of philosophy; hermeneutics, the study of 
interpretation, and phenomenology, the 
examination of the foundations of 
experience and action. 

Part II presents a critical view of AI. 
The authors discuss their feeling that, 
while there may be useful spinoffs, the 
grandiose goals of AI will not be met 
because the approaches are rooted too 
deeply in the rationalistic tradition and its 
assumptions about intelligence, language, 
and formalization. 

The last part of the book uses the ideas 


Although this is a 
fascinating and 
provocative book, I am 
afraid it will not reach 
the audience it 
deserves. 


about the nature of language and action to 
propose a new foundation for design. The 
new approach shifts concern away from 
the usual technology-oriented focus of 
system development methods. Communi¬ 
cation is not viewed merely as a process 
of transmitting information or symbols, 
but as a phenomenon concerned with 
commitment and interpretation. Thus, to 
deal with the question “What can people 
do with computers?” the authors examine 
what people do in a domain of linguistic 
action. For example, the manager of an 
organization is characterized as articulat¬ 
ing and activating a network of commit¬ 
ments, produced primarily through 
promises and requests. The manager 
participates in “conversations for 
possibilities” that open the way to new 
actions. The authors conclude that 
because models of rationalistic problem 
solving do not reflect how actions are 


really determined, programs based on 
such models are unlikely to prove 
successful. 

Nevertheless, there is a role for 
technology in support of managers and as 
an aid for coping with the complex 
conversational structure generated within 
an organization. As an example, the 
authors describe a computer program 
called a “coordinator” that is designed for 
constructing and controlling conversation 
networks in large-scale distributed 
communications systems. The coordina¬ 
tor makes interactions “transparent,” and 
provides a tool that operates in the 
domain of “conversations for action.” 

The book concludes with an impas¬ 
sioned appeal: 

We are engaging in a philosophical 
discourse about the self — about what we 
can do and what we can be. Tools are 
fundamental to action, and through our 
actions we generate the world. The 
transformation we are concerned with is not 
a technical one, but a continuing evolution 
of how we understand our surroundings and 
ourselves — of how we continue becoming 
the beings that we are. 

Although this is a fascinating and 
provocative book, I am afraid it will not 
reach the audience it deserves. AI 
researchers will have little interest in the 
more-practical design ideas in the last 
part of the book, and engineers interested 
in the design aspects may find themselves 
somewhat weary after 140 pages of the 
philosophy of language and discussions 
about AI. 

To reach the intended audiences, the 
book should have been divided into two 
works, one dealing with the philosophical 
ideas and criticisms of AI and the other 
devoted to design issues. The design 
book could have avoided some of the 
philosophical jargon and concentrated 
instead on examples and case studies 
aimed at raising the consciousness of 
designers to the fact that “in designing 
tools we are designing ways of being.” 

Oscar Firschein 
SRI International 
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Computer Networks (2nd edition) 


Andrew S. Tanenbaum (Prentice Hall, 
Englewood Cliffs, N.J., 1988, 658 pp., 
$37.50) 

Andrew Tanenbaum wrote the first 
edition of Computer Networks in 1981. 

As in the textbooks he has authored on 
other computer fields, Tanenbaum’s 
primary goal appeared to be to present an 
organized structure for the material rather 
than to list in a monolithic fashion all the 
important information in the field. The 
former approach provides a framework 
into which the student can assimilate 
information long after the course is over. 

What resulted was a text organized on 
the seven recently defined layers of the 
International Standards Organization’s 
model for Open Systems Interconnection. 


The packet assembler/disassembler 
definition is now in Chapter 9, which 
covers the application layer. 
Long-haul broadcast and local-area- 
network information is now folded 
into the appropriate chapters (the 
physical layer and medium access 
control sublayer chapters, respec¬ 
tively) for discussion alongside the 
point-to-point protocols. The MAC 
sublayer chapter also discusses the 
IEEE 802 series of LAN standards. 
The information from the abandoned 
topology chapter is distributed 
between the chapter on the network 
layer and an appendix on queueing 
theory. 

Error detection/correction material is 
now in the data link layer chapter. 


Computer Networks is a large, complex book, but it 
simply reflects the complexity of the technology and 
standards. 


The dilemma of this approach at the time 
was that industry had not yet embraced 
the OS I model, so Tannenbaum had to to 
coerce his examples — Arpanet, Systems 
Network Architecture, and DECNet — 
into fitting that model. In addition, the 
layer definitions were still being revised, 
leaving many of the definitions in the 
first edition vague and unsatisfying. 

In his second edition, Tanenbaum has 
taken advantage of the maturing of the 
data communications field and has come 
up with a more complete and even- 
handed survey. 

He discusses what standardization has 
done to the industry, both positive and 
negative. He recognizes that many newer 
standards have rejected the single data 
link layer, and he consequently has split 
the first edition’s chapter on the layer 
into two chapters: medium access and 
data link. New standards such as the 
Integrated Services Digital Network, 
Manufacturing Automation Protocol, 
Usenet, and Bitnet receive extensive 
coverage, especially ISDN. Discussions 
in the final chapter on applications now 
include file transfer, mail, virtual 
terminals, and directories. 

In general, examples seem to make up 
a larger percentage of the book this time 
around (the theory has not shrunk — the 
book has grown!), making it a bit harder 
for instructors to cover the material in the 
same time they allotted in the past. 

For those of you familiar with the first 
edition, here is a list of the main organ¬ 
izational changes from it: 


• Internetworking is now in the 
network layer chapter. 

• The book now has a full chapter on 
the session layer, including a 
discussion of remote procedure calls. 

All of the above changes represent a 
firming up of the material rather than a 
fundamental organizational change. By 
adhering to the OSI model, imperfect 
though it might seem to some, Tanen¬ 
baum has once again placed his discus¬ 
sion of data communications in a 
conceptual framework and has left the 
details of the exemplary protocols to 
standards documents and other texts. In 
using this book for a course, therefore, it 
is much easier to leave out some of the 
examples without risking the students’ 
understanding of a particular type of 
protocol or layer. On the other hand, this 
edition is hardly more useful than the 
first for in-depth training in any particular 
communications system, and should not 
be used for such purposes. Many such 
texts do exist for the lower layers. 

Tanenbaum’s Computer Networks is a 
large, complex book, but it simply 
reflects the complexity of the technology 
and standards that it covers. I recommend 
the text for a core course in communica¬ 
tions and networks in a computer science 
or engineering curriculum, or for 
technical readers who want to understand 
what is going on in this fast-growing 
field. 

James E. Heliotis 

Rochester Institute of Technology 


Numerical Recipes in 
C: The Art of 
Scientific Computing 

William H. Press, Brian P. Flannery, 

Saul A. Teukolsky, and William T. 

Vetterling (Cambridge University 

Press, New York, 1988, 735 pp., 

$44.50) 

The field of numerical analysis is one 
of many disciplines that have gained 
much from the significant increases in the 
computational power of computer 
systems. But however efficient these 
systems become, researchers and 
engineers must remember that at the heart 
of numerical analysis lies solid mathe¬ 
matics. 

This point is well made in Numerical 
Recipes in C. Some books on this subject 
give a detailed description of the 
mathematical basis of these numerical 
methods, but then leave the reader flat 
when he or she wants to actually 
implement some of the routines. On the 
other hand, a number of texts treat these 
algorithms as “black boxes,” with 
sufficient information on the coding and 
implementation but a generally inade¬ 
quate mathematical background. 
Fortunately, this is an impressive book 
that discusses a wide range of analytical 
topics and gives clear, concise algorithms 
and well-written code throughout. 

As stated in the preface, the authors’ 
intent is to set a clear standard for 
scientific computing in the C language. 
The general opinion among technical 
programmers that I have talked to (and 
the opinion of the authors) is that Fortran 
will not disappear any time soon, but that 
the C language is increasingly a serious 
competitor. A familiarity with C is 
necessary to utilize the routines in the 
book, and a firm understanding of 
undergraduate mathematics is definitely 
required to fully grasp the underlying 
analytical concepts. This book is 
probably most suitable for a text or 
reference for a graduate course in 
numerical analysis or as a professional 
reference for engineers or scientists using 
numerical methods in their work. 

Presumably because the C language 
takes some getting used to, even by long¬ 
time hard-core Fortran programmers, the 
authors spend an adequate amount of 
time in the first chapter discussing the 
concepts and structure of C and error/ 
accuracy considerations. However, 
keeping a good book on C at hand while 
reading this chapter will certainly be of 
great benefit. 

All the standard topics are then dealt 
with on a chapter-by-chapter basis in a 
well-written sequence of mathematical 
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development, algorithm development, 
and finally code listing and analysis. The 
topics include: solution of linear 
equations and eigensystems, interpola¬ 
tion, integration, root finding, the special 
functions, Fourier transforms, and 
differential equations. I was pleased to 
find some topics usually presented only 
in dedicated texts, such as statistics and 
modeling, boundary value problems, and 
partial differential equations. Surpris¬ 
ingly, this book also has full sections on 
sorting and random numbers, fields not 
normally associated with numerical 
analysis. 

An added bonus is the occasional 
inclusion of special cases and areas of 
interest within the major topics, including 
sparse linear systems, two-dimensional 
interpolation, the data encryption 
standard, and linear programming. This 
might especially interest some people 


This is an impressive 
book that discusses a 
wide range of 
analytical topics. 


who have encountered these subjects 
before but did not have the time to 
investigate them further. 

Two items I particularly appreciated, in 
that they made the code relationships 
easier to follow, were the alphabetical 
listings of the routines and subroutines in 
the front and back of the book. One 
feature I found slightly distracting, 
however, was the listing of references 
after each section instead of each chapter. 
The numerous reference listings are 
nonetheless very useful, and it might also 
help to have some of them handy while 
reading the text. 

The book is written in a refreshing, 
conversational style, which definitely 
helps in comprehending the material, and 
the careful reader might even pick up 
some subtle humor. As is usually the case 
with books of this type, the program 
sources can be ordered on magnetic 
media from the publisher in a variety of 
formats. A companion text entitled 
Numerical Recipes Example Book gives 
additional detailed code listings, many 
examples and test data, and is definitely 
meant to be purchased along with the 
main text. 

In summary, the vast amount of well- 
presented information in Numerical 
Recipes in C definitely deserves to be in 
the personal or professional library of 
engineers and scientists who utilize the 
power of numerical analysis. 

Robert Kozlowski 

Killam Associates 


Neurocomputing: Foundations of Research 


James A. Anderson and Edward 

Rosenfeld, eds. (MIT Press, Cam¬ 
bridge, Mass., 1988, 729 pp., $55) 

When I met Warren McCulloch at MIT 
in 1962, he showed me his mathematical 
model of a brain cell (“the McCulloch- 
Pitts neuron”). He said he was led to it in 
his quest to learn “What is a number that 
a man may know it, and what is man that 
he may know a number?” 

These functions held a short-term 
fascination, but other mathematics led me 
away. Twenty-four years later I learned 
how J.J. Hopfield had combined large 
numbers of interconnecting neurons into 
a system that could be easily programmed 
(weighted) to work in parallel, thus 
efficiently accomplishing tasks that were 
terribly unsuitable for serial computers. 
Namely, they performed pattern recogni¬ 
tion and completion; this is how people 
compute and do so much more effectively 
than computers do. I have become 
convinced that these constructions 
indicate the true path towards 
McCulloch’s man-number Holy Grail. 

This brief autobiographical cross 
section is a microcosm of the neurocom¬ 
puting field, also known as (artificial) 
neural networks (or (A)NN), connection- 
ism, parallel distributed processing, sixth- 
generation computing, reverse engineer¬ 
ing of brains, and biologically inspired 
computing systems. 

Like AI, neurocomputing was born in 
hyperbole and was forced into retreat by 
the resulting backlash. Its survival, 
though, was assured by a century of 
groundwork laid by psychologist William 
James, mathematician John von Neu¬ 
mann, and neurobiologists Warren 
McCulloch, Walter Pitts, and Donald 
Hebb. 

I could fill this review with many more 
names and bibliographical citations, but 
that’s what’s in Neurocomputing'& 43 
sections, each containing one or two 
seminal research papers and preceded by 
a two-page introduction to put things in 
perspective (with several bibliographical 
citations forward and backwards in time). 
The book also has a lengthy introduction 
and afterword, and a common name index 
and a subject index. 

The collection makes it clear that the 
field’s quarter-century hibernation was 
by no means lifeless. The 1960s seemed a 
little slow, but beginning in 1969 about 
three seminal research papers appeared 
each year. Currently, about half a dozen 
international neurocomputing “killer- 
conferences” are held annually, with 
enthusiastic participation by mathemati¬ 
cians, computer scientists, engineers, 


biologists, and psychologists (in roughly 
equal numbers) symbiotically developing 
this fascinating, rich field. 

Neurocomputing seems to be unifying 
itself, characterized as follows (this 
example is very simple). A system 
consists of a collection of interconnected 
neurons, where the instantaneous value of 
the ith neuron is s , which we describe 
compactly by a column vector, S (it helps 
to think of the neurons, at least initially, 
as flip-flops). The neuromorphic analogy 
of a serial computer’s fetch-execute 
cycle, which I will call the NNFEC, is 
given by S «- 0(^5) where W is a matrix 
of interconnection strengths and a intro¬ 
duces nonlinearity. For example, a could 
be signum, a smooth sigmoidal function 
such as arctan or tanh, or a stochastic 


If you have a free 
weekend, nothing is 
better than 
Neurocomputing, but 
prepare to be 
consumed. 


function. 

The NNFEC implementation mecha¬ 
nism (whether biological, electronic, or 
software simulated) provides many 
opportunities for parallel operation and 
even nondeterministic behavior. We can 
think of the matrix operation WS as a 
large number of simultaneous scalar (or 
smaller vector) operations and assign¬ 
ments; these can be done in parallel, 
sequentially, sequentially in a random 
order, or asynchronously. The program or 
long-term memory of our system is stored 
in the connection matrix W. For various 
effects, the architecture of W can be 
constrained to be triangular or symmetric 
or a structured combination of such 
simple forms. 

The book presents a variety of 
interpretations and structures based on 
the above theme. The important areas of 
research emerge as learning (that is, 
programming or determining the weights 
used in W) and representations (which 
resembles the data structures problem of 
more-traditional programming). 

Various learning algorithms are 
known, from Rosenblatt’s 1958 per- 
ceptron convergence procedure that 
shows how to train a single McCulloch- 
Pitts neuron by presenting it with 
questions for which the trainer knows the 
correct answers and can iteratively adjust 
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the weights, to the backwards error 
propagation (or backprop) algorithm for 
an acyclic network of such neurons, to a 
simple formula used by Hopfield to 
encode the patterns the machine is to 
learn. 

The problem of representations can 
best be presented here by a pair of 
examples. 

(1) A neuromorphic system that 
deals with quantity will find “thermome¬ 
ter code” friendlier than binary (5 in the 


range 0..15 can be represented by 
1111100000000000 or 0101, respec¬ 
tively). 

(2) A system that recognizes 
objects in a picture similarly finds pixels 
or sensory data unfriendly; its needs are 
lines, curves, boundaries, contrasts, and 
contiguous objects. These are, in fact, the 
results of preprocessing by retinas in 
mammalian visual systems. 

Given this brief overview, if you think 
you may want to study neurocomputing 


and you have a free evening, read 
Richard Lippmann’s survey article, “An 
Introduction to Computing with Neural 
Nets,” in the April 1987 issue of IEEE 
Acoustics , Speech, and Signal Process¬ 
ing. If you already know this is the field 
for you, and if you have a free weekend, 
nothing is better than Neurocomputing , 
but prepare to be consumed. 

Peter G. Anderson 

Rochester Institute of Technology 


The Conquest of the Microchip 


Hans Queisser (translated by Diane 

Crawford-Burkhardt) (Harvard 

University Press, Cambridge, Mass., 

1988, 200 pp„ $24.95) 

This book is an interesting tale of that 
momentous invention/discovery, the 
microchip. Despite the fact that the book 
is translated from German, it reads 
smoothly. It is intended as a history, with 
brief descriptions of the technological 
devices. It includes no equations and just 
eight figures, ranging from the world 
trade balance to a diagram of a junction 
transistor. Consequently, the book is not 
bogged down with details like a pro¬ 
tracted discussion of quantum mechanics. 
“We are approaching the end of the Iron 
Age . . . The coming era is the Age of 
Silicon” is a good summary of the 
author’s viewpoint. 

The book would be appropriate in an 
undergraduate engineering humanities 
class focusing on aspects of modern 
technology (with books like Nader’s 
Unsafe at Any Speed , Pirsig’s Zen and 
the Art of Motorcycle Maintenance, 
Petroski’s Beyond Engineering, and other 
narratives providing ethical or historical 
perspectives on scientific issues). The 
practicing engineer would probably enjoy 
the author’s European perspective and 
might also benefit from the book, as 
some gaps probably exist in his or her 
historical knowledge. The book could 
easily become an interesting public- 
television special. 

The first eight chapters deal directly 
and chronologically with the microchip’s 
history, while the remaining three 
chapters present political and economic 
ramifications along with future specula¬ 
tions. The first chapter begins with 
Marchese Guglielmo Marconi in 1895 
(with a brief return to 1850 and the birth 
of Ferdinand Braun). The history 
progresses through X rays and radar, 
followed by a whole chapter devoted to 
AT&T and Bell Laboratories. After 
covering the invention of the transistor, 
the author details the device’s transition 
to the marketplace and its eventual 


application in computers. The last 
historical chapter describes the Japanese 
entry into the semiconductor arena (this 
chapter’s title, “Handotai Senso,” means 
“semiconductor war”). The description of 
the Japanese Ministry of International 
Trade and Industry is useful and interest¬ 
ing. 

The author’s original intended 
audience was the general European 
community. He notes that the original 
volume “set forth Europe’s comparative 
position [in microchip technology] in 
some detail, and might have contributed 
to public awareness.” This edition 
includes chapters on the United States 
and Japan, so the emphasis is worldwide 
(as it should be). 

The author’s unique perspective 
derives from his European training 
combined with some work in the Silicon 
Valley (he worked for Nobel laureate 
William Shockley in an apricot barn in 
Mountain View, California). The 
collection of photographs (including 
Laue’s X-ray machine, an aerial view of 
Bell Labs, and the first assembled point 
contact) is intriguing, especially the 
emphasis on Europeans. I particularly 
enjoyed the inclusion of such individuals 


as Konrad Zuse, who the author calls the 
“father of the first real digital computer.” 

The bibliography should have included 
many more in-depth historical and 
technical references. For example, the 
story of Shockley, Bardeen, Brattain, and 
the Nobel Prize-winning invention of the 
transistor is particularly fascinating and 
needs more than one technical and 
biographical reference. 

The author is at his best describing his 
own experience in the Silicon Valley. His 
political and economic discussions center 
on Europe, which he admits has not been 
a hotbed of microchip production and 
research. Personally, I think he is hard on 
Europe (and, perhaps, not hard enough on 
the rest of the world). His political 
speculations are quite interesting, ranging 
from the balancing of lifestyles between 
East and West to the Soviet Union’s 
problem of making computers widely 
available while controlling information. 

I hope this book acts as a catalyst for 
academic and business action. As the 
author states, “We cannot look at the 
world with just one eye.” 

Lisa M. Anneberg 

Wayne State University 
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Breakthrough in presentation of simulation results 
SIMSCRIPT II.5 with SIMGRAPHICS 
Now you see an animated picture of the system 



SIMGRAPHICS ™ scenario preparation 


SIMGRAPHICS menu builder 



Free trial and training 

See for yourself how simulation 
results are now easier to understand. 

The free trial contains everything 
you need to try SIMGRAPHICS™ 
on your computer. 

We send you SIMSCRIPT II.5, 
animated models, and complete 
documentation. You can build your 
own model or modify one of ours. 

Try the SIMSCRIPT II.5® lan¬ 
guage, the timeliness of our support, 
the accuracy of our documentation, 
and the facilities for error checking- 
everything you need for a successful 
project. 

No cost, no obligation. 

Act now for free training 

For a limited time we will also in¬ 
clude free training. 

For immediate information 

Call Hal Duncan at (619) 457-9681. 
In the UK, call Richard Eve on (01) 
528-7980. 




Map with moving objects Combined discrete-continuous 



enrollment worth $950. 

□ Send information on your Special 
University Offer. 




























